Sie sind auf Seite 1von 388

Oracle Database 11g: New

Features for Administrators

Volume I Student Guide

D50081GC10
Edition 1.0
July 2007
D51900 L$


Authors Copyright 2007, Oracle. All rights reserved.

Christian Bauwens Disclaimer


Maria Billings This course provides an overview of features and enhancements planned in release
Christine Jeal 11g. It is intended solely to help you assess the business benefits of upgrading to 11g
Srinivas Putrevu and to plan your IT projects.

James Spiller This course in any form, including its course labs and printed matter, contains
Kesavan Srinivasan proprietary information that is the exclusive property of Oracle. This course and the
information contained herein may not be disclosed, copied, reproduced, or distributed
Jenny Tsai
to anyone outside Oracle without prior written consent of Oracle. This course and its
Jean-Francois Verrier contents are not part of your license agreement nor can they be incorporated into any
James Womack contractual agreement with Oracle or its subsidiaries or affiliates.

This course is for informational purposes only and is intended solely to assist you in
Technical Contributors planning for the implementation and upgrade of the product features described. It is
and Reviewers not a commitment to deliver any material, code, or functionality, and should not be
relied upon in making purchasing decisions. The development, release, and timing of
Maqsood Alam any features or functionality described in this document remain at the sole discretion
Kalyan Bitra of Oracle.

Harald Van Breederode This document contains proprietary information and is protected by copyright and
Edward Choi other intellectual property laws. You may copy and print this document solely for your
own use in an Oracle training course. The document may not be modified or altered in
Al Flournoy any way. Except where your use constitutes "fair use" under copyright law, you may
Andy Fortunak not use, share, download, upload, copy, print, display, perform, reproduce, publish,
Gerlinde Frenzen license, post, transmit, or distribute this document in whole or in part without the
express authorization of Oracle.
Greg Gagnon
Joel Goodman The information contained in this document is subject to change without notice. If you
find any problems in the document, please report them in writing to: Oracle University,
Hansen Han
500 Oracle Parkway, Redwood Shores, California 94065 USA.
Uwe Hesse Restricted Rights Notice
Sunil Hingorani
If this documentation is delivered to the United States Government or anyone using
Magnus Isaksson the documentation on behalf of the United States Government, the following notice is
Susan Jang applicable:
Martin Jensen
U.S. GOVERNMENT RIGHTS
Pete Jones The U.S. Governments rights to use, modify, reproduce, release, perform, display, or
Yash Kapani disclose these training materials are restricted by the terms of the applicable Oracle
license agreement and/or the applicable U.S. Government contract.
Pierre Labrousse
Richard.W.Lewis Trademark Notice
Hakan Lindfors
Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other
Russ Lowenthal names may be trademarks of their respective owners.
Kurt Lysy
Silvia Marrone This document is not warranted to be error-free.

Heejin Park
Editors
Jagannath Poosarla
Eric Siglin Raj Kumar
Ranbir Singh Daniel Milne
Jeff Skochil Vijayalakshmi Narasimhan
George Spears Atanu Raychaudhuri
Birgitte Taagholt Richard Wallis
Glenn Tripp
Anthony Woodell
Publishers
Sujatha Nagendra
Graphic Designers Srividya Rameshkumar
Rajiv Chandrabhanu Michael Sebastian
Samir Mozumdar Jobi Varghese
Introduction

Copyright 2007, Oracle. All rights reserved.


Overview

This course focuses on those features of Oracle


Database 11g that are applicable to database
administration.
Previous experience with Oracle databases
(particularly Oracle Database 10g) is required for a
full understanding of many of the new features.
Hands-on practices emphasize functionality rather
than test knowledge.

I-2 Copyright 2007, Oracle. All rights reserved.

Overview
This course is designed to introduce you to the new features of Oracle Database 11g that are
applicable to the work usually performed by database administrators and related personnel. The
course does not attempt to provide every detail about a feature or cover aspects of a feature that
were available in previous releases (except when defining the context for a new feature or
comparing past behavior with current behavior). Consequently, the course is most useful to you
if you have already administered other versions of Oracle databases, particularly Oracle
Database 10g. Even with this background, you should not expect to be able to implement all of
the features discussed in the course without supplemental reading, especially the Oracle
Database 11g documentation.
The course consists of instructor-led lessons and demonstrations, plus many hands-on practices
and demos that enable you to see for yourself how certain new features behave. As with the
course content in general, these practices are designed to introduce you to the fundamental
aspects of a feature. They are not intended to test your knowledge of unfamiliar syntax or to
provide an opportunity for you to examine every nuance of a new feature. The length of this
course precludes such activity. Consequently, you are strongly encouraged to use the provided
scripts to complete the practices rather than struggle with unfamiliar syntax.

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


Oracle Database Innovation
Audit Vault
Database Vault
Secure Enterprise Search
Grid Computing
Automatic Storage Mgmt
Self Managing Database
XML Database
Oracle Data Guard
Real Application Clusters
Flashback Query
of sustained Virtual Private Database
Built-in Java VM
innovation Partitioning Support
Built-in Messaging
Object Relational Support
Multimedia Support
Data Warehousing Optimizations
Parallel Operations
Distributed SQL & Transaction Support
Cluster and MPP Support
Multi-version Read Consistency
Client/Server Support
continuing with
Platform Portability
Commercial SQL Implementation Oracle Database 11g

I-3 Copyright 2007, Oracle. All rights reserved.

Oracle Database Innovation


As a result of its early focus on innovation, Oracle has maintained the lead in the industry with a
large number of trend-setting products. Continued emphasis on Oracles key development areas
has led to a number of industry firstsfrom the first commercial relational database, to the first
portable tool set and UNIX-based client/server applications, to the first multimedia database
architecture.

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


Enterprise Grid Computing

SMP RAC Managing


Grids of
dominance clusters change
low-cost
for hardware and across the
availability storage enterprise

I-4 Copyright 2007, Oracle. All rights reserved.

Enterprise Grid Computing


Oracle Database 10g was the first database designed for grid computing. Oracle Database 11g
consolidates and extends Oracles unique ability to deliver the benefits of grid computing. Oracle
Infrastructure grids fundamentally changed the way data centers look and operate, transforming
data centers from silos of isolated system resources to shared pools of servers and storage.
Oracles unique grid architecture enables all types of applications to scale-out server and storage
capacity on demand. By clustering low-cost commodity server and storage modules on
Infrastructure grids, Oracle Database 11g enables customers to improve their user service levels,
reduce their down time, and make more efficient use of their IT resources while still increasing
the performance, scalability, and security of their business applications.
Oracle Database 11g furthers the adoption of grid computing by offering:
Unique scale-out technology with a single database image
Lower server and storage costs
Increased availability and scalability

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


Oracle Database 11g: Focus Areas

Manageability
Availability
Performance
Business intelligence and data warehousing
Security

I-5 Copyright 2007, Oracle. All rights reserved.

Oracle Database 11g: Focus Areas


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

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


Oracle Database 11g: Focus Areas

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

I-6 Copyright 2007, Oracle. All rights reserved.

Oracle Database 11g: Focus Areas (continued)


The Oracle Infrastructure grid provides the additional functionality required to manage all the
information in the enterprise with robust security, information lifecycle management, and
integrated business intelligence analytics to support fast and accurate business decisions at the
lowest cost.

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


Management Automation

Auto-tuning

Advisory

Instrumentation

Recovery

Replication
RAC
Memory

Schema
Apps/SQL
Backup
Storage

I-7 Copyright 2007, Oracle. All rights reserved.

Management Automation
Oracle Database 11g continues the effort begun in Oracle9i Database and carried on through
Oracle Database 10g to dramatically simplify and ultimately, fully automate the tasks that DBAs
must perform. What is new in Oracle Database 11g is Automatic SQL Tuning with self-learning
capabilities. Other new capabilities include automatic, unified tuning of both SGA and PGA
memory buffers, and new advisors for partitioning, database repair, streams performance, and
space management. Enhancements to Oracle Automatic Database Diagnostic Monitor (ADDM)
give it a better global view of performance in Oracle Real Application Clusters (RAC)
environments and improved comparative performance analysis capabilities.

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


Self-Managing Database: The Next Generation

Manage performance and resources


Manage
change
Manage fault

I-8 Copyright 2007, Oracle. All rights reserved.

Self-Managing Database: The Next Generation


Self-management is an ongoing goal for Oracle Database.
Oracle Database 10g marked the beginning of a major effort to make the database easy to use.
With Oracle Database 10g, the focus for self-managing was on performance and resources.
Oracle Database 11g adds two important axes to the overall self-management goal: change
management and fault management.

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


Suggested Additional Courses

Oracle Database 11g: Real Application Clusters


Oracle Database 11g: Data Guard Administration
Oracle Enterprise Manager 11g Grid Control

I-9 Copyright 2007, Oracle. All rights reserved.

Suggested Additional Courses


For more information about the key grid computing technologies used by the Oracle products,
you can obtain additional training from Oracle University (courses listed in the slide).

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


Further Information

For more information about topics that are not covered in


this course, refer to the following:
Oracle Database 11g: New Features Overview Seminar
Oracle Database 11g: New Features eStudies
http://www.oracle.com/education/library
A comprehensive series of self-paced online courses
covering all new features in detail
Oracle By Example series: Oracle Database 11g
http://otn.oracle.com/obe/obe11gdb/index.html
Oracle OpenWorld events
http://www.oracle.com/openworld/index.html

I - 10 Copyright 2007, Oracle. All rights reserved.

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


Suggested Schedule

Topic Lessons Day

Installation & Upgrade I, 1 1

Manage Storage 2 1

Manage Change 3, 4, 5 2

Manage Performance & Resources 6, 7, 8, 9 3

Manage Availability 10, 11, 12, 13 4

Manage Security 14, 15 5

Miscellaneous 16 5

I - 11 Copyright 2007, Oracle. All rights reserved.

Suggested Schedule
The lessons in this guide are arranged in the order in which you will probably study them in the
class. The lessons are grouped into topic areas, but they are also organized by other criteria,
including the following:
A feature is introduced in an early lesson and then referenced in later lessons.
Topics alternate between difficult and easy to facilitate learning.
Lessons are supplemented with hands-on practices throughout the course to provide regular
opportunities for you to explore what you are learning.
If your instructor teaches the class in the sequence in which the lessons are printed in this guide,
the class should run approximately as shown in the schedule. Your instructor, however, may vary
the sequence of the lessons for a number of reasons, including:
Customizing material for a specific audience
Covering a topic in a single day instead of splitting the material across two days
Maximizing the use of course resources (such as hardware and software)

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


Installation and Upgrade
Enhancements

Copyright 2007, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to:


Install Oracle Database 11g
Upgrade your database to Oracle Database 11g
Use hot patching

1-2 Copyright 2007, Oracle. All rights reserved.

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


Oracle Database 11g Installation: Changes

Minor modifications to the install flow, with new


screens for:
Turning off secure configuration in the seed database
Setting the out-of-box memory target
Specifying the database character set
Modifications to OS authentication to support SYSASM
Addition of new products to the install:
Oracle Application Express
Oracle Configuration Manager (OCM)
SQL Developer
Warehouse Builder (server-side pieces)
Oracle Database Vault

1-3 Copyright 2007, Oracle. All rights reserved.

Oracle Database 11g Installation: Changes


During an Oracle Database 11g installation, you will notice several changes to the installation
process. These changes include standard database out-of-box memory calculations, character set
determination, support for the new SYSASM role, and a corresponding operating system privileges
group (OSASM) that is intended to secure privileges to perform ASM administration tasks.
The following are the new components that are available when you install Oracle Database 11g:
Oracle Application Express is installed with Oracle Database 11g. It was previously named
HTML DB and was available as a separate companion CD component.
Oracle Configuration Manager is offered during installation. It was previously named
Customer Configuration Repository (CCR). It is an optional component for database installation.
Oracle Configuration Manager gathers and stores details relating to the configuration of the
software stored in Oracle Database home directories.
Oracle SQL Developer is installed by default with template-based database installations, such
as General Purpose/Transaction Processing and Data Warehousing. It is also installed with
database client Administrator, Runtime, and Custom installations.
Oracle Warehouse Builder is installed with Oracle Database 11g.
Oracle Database Vault is installed with Oracle Database 11g. It is an optional component for
database installation. It was previously available as a separate companion CD component.

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


Oracle Database 11g Installation: Changes

Move to JDK/JRE 1.5


Removal of certain products and features from the
installation:
OEM Java Console
Raw storage support for data files (installer only)
Oracle Data Mining Scoring Engine
Oracle Workflow
iSQL*Plus
Addition of new prerequisite checks (largely feedback
from SAP and various other bugs)
Changes to the default file permissions

1-4 Copyright 2007, Oracle. All rights reserved.

Oracle Database 11g Installation: Changes (continued)


The following components are part of Oracle Database 10g, Release 2 (10.2) but are not available for
installation with Oracle Database 11g:
iSQL*Plus
Oracle Workflow
Oracle Data Mining Scoring Engine
Oracle Enterprise Manager Java Console

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


Oracle Database 11g Installation: Changes

Minor changes to the clusterware installation:


Support for block devices for storage of OCR and Voting
Disks
Support for upgrade of XE databases directly to
Oracle Database 11g
Better conformance to OFA in the installation:
Prompt for ORACLE_BASE explicitly
Warnings in the alert log when ORACLE_BASE is not set

1-5 Copyright 2007, Oracle. All rights reserved.

Oracle Database 11g Installation: Changes (continued)


In Oracle Database 11g, Oracle Universal Installer (OUI) prompts you to specify the Oracle base.
The Oracle base that you provide during installation is logged in the local inventory. You can share
this Oracle base across all of the Oracle homes that you create on the system. Oracle recommends
that you share an Oracle base for all of the Oracle homes created by a user.
Oracle Universal Installer has a list box in which you can edit or select the Oracle base. The installer
derives the default Oracle home from the Oracle base location that you provide in the list box.
However, you can change the default Oracle home by editing the location.
The following are changes made in Oracle Database 11g with respect to the Oracle base to make it
compliant with Optimal Flexible Architecture (OFA):
ORACLE_BASE is a recommended environment variable. (This variable will be mandatory in
future releases.)
By default, the Oracle base and the Oracle Clusterware home are at the same directory level
during Oracle Clusterware installation. You should not create an Oracle Clusterware home under
the Oracle base. Because, specifying an Oracle Clusterware home under the Oracle base results
in an error.
Oracle recommends that you create the flash recovery area and the data file location under the
Oracle base.

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


Oracle Database 11g Installation Changes (continued)
In Oracle Database 10g, the default flash recovery area and the data file location are one level
above the Oracle home directory. However, in Oracle Database 11g, the Oracle base is the
starting point to set the default flash recovery area and the data file location. Nevertheless,
Oracle recommends that you keep the flash recovery area and data file location on separate
disks.

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


Oracle Database 11g: Software Installation

1-7 Copyright 2007, Oracle. All rights reserved.

Oracle Database 11g: Software Installation


The Oracle Database 11g software installation is a straightforward process. As the operating system
oracle user, change directory to Disk1 on your installation media or software staging directory,
and then start Oracle Universal Installer (OUI):
$ ./runInstaller
Select Oracle Database 11g on the Select a Product to Install page and click Next. On the Select
Installation Method page, provide the Oracle base (if the ORACLE_BASE parameter has not been
set) and Oracle home locations. The default installation type and UNIX DBA group values are
Enterprise Edition and dba, respectively. You must use the Advanced/Custom installation
path to install many of the Enterprise Edition options (such as Real Application Testing).
Starting with Oracle Database 11g, OUI tries to install its inventory in $ORACLE_BASE/..
As a result, you must ensure that $ORACLE_BASE/.. is writable by any user installing the Oracle
software. This translates to the following (as root user):
# mkdir -p /u01/app
# chgrp oinstall /u01/app
# chmod 775 /u01/app
However, if you are running previous versions of the Oracle software, OUI uses the inventory that
already exists.

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


Oracle Database 11g: Software Installation

1-8 Copyright 2007, Oracle. All rights reserved.

Oracle Database 11g: Software Installation (continued)


On the Product-Specific Prerequisite Checks page, your system is examined for supported operating
systems and kernels, required RPMs, Oracle environment consistencies, and so on.
If no discrepancies are discovered, proceed with the installation by clicking Next. Review the
information on the Summary page, and then click Install.

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


Practice 1-1: Overview

In this practice, you install the Oracle Database 11g


software.

1-9 Copyright 2007, Oracle. All rights reserved.

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


Oracle Database Upgrade Enhancements

Pre-Upgrade Information Tool


Simplified upgrade
Upgrade performance enhancement
Post-Upgrade Status Tool

1 - 10 Copyright 2007, Oracle. All rights reserved.

Oracle Database Upgrade Enhancements


Oracle Database 11g, Release 1 continues to make improvements to simplify manual upgrades,
upgrades performed using the Database Upgrade Assistant (DBUA), and downgrades.
The DBUA provides the following enhancements for single-instance databases:
Support for improvements to the pre-upgrade tool in the areas of space estimation, initialization
parameters, statistics gathering, and new warnings
The catupgrd.sql script performs all upgrades and the catdwgrd.sql script performs all
downgrades, for both patch releases and major releases.
The DBUA can automatically take into account multi-CPU systems to perform parallel object
recompilation.
Errors are now collected as they are generated during the upgrade and displayed by the Post-
Upgrade Status Tool for each component.

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


Pre-Upgrade Information Tool

SQL script (utlu111i.sql) analyzes the database to


be upgraded.
Checks for parameter settings that may cause upgrade
to fail and generates warnings
Utility runs in old server and old database context.
Provides guidance and warnings based on the Oracle
Database 11g, Release 1 upgrade requirements
Supplies information to the DBUA to automatically
perform required actions

1 - 11 Copyright 2007, Oracle. All rights reserved.

Pre-Upgrade Information Tool


The Pre-Upgrade Information Tool analyzes the database to be upgraded. It is a SQL script that ships
with Oracle Database 11g, Release 1 and must be run in the environment of the database being
upgraded. This tool displays warnings about possible upgrade issues with the database.
It also displays information about the required initialization parameters for Oracle Database 11g,
Release 1.

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


Pre-Upgrade Analysis

The Pre-Upgrade Information Tool checks for:


Database version and compatibility
Redo log size
Updated initialization parameters (for example,
SHARED_POOL_SIZE)
Deprecated and obsolete initialization parameters
Components in database (JAVAVM, Spatial, and so on)
Tablespace estimates
Increase in total size
Additional allocation for AUTOEXTEND ON
SYSAUX tablespace

1 - 12 Copyright 2007, Oracle. All rights reserved.

Pre-Upgrade Information Analysis


After installing Oracle Database 11g, you should analyze your database before upgrading it to the
new release. This is done by running the Pre-Upgrade Information Tool. This is a necessary step if
you are upgrading manually. It is also recommended if you are upgrading with the DBUA so that you
can preview the items that the DBUA checks. The Pre-Upgrade Information Tool is a SQL script that
ships with Oracle Database 11g and must be copied to and run from the environment of the database
being upgraded. To run the tool, follow these steps:
1. Log in to the system as the owner of the Oracle Database 11g Oracle home directory.
2. Copy the Pre-Upgrade Information Tool (utlu111i.sql) from the Oracle Database 11g
ORACLE_HOME/rdbms/admin directory to a directory outside of Oracle home (such as /tmp).
3. Log in to the system as the owner of the Oracle home directory of the database to be upgraded.
4. Change to the directory that you copied the files to. Then start SQL*Plus.
5. Connect to the database instance as a user with SYSDBA privileges.
6. Set the system to spool results to a log file for later analysis:
SQL> SPOOL upgrade_info.log
7. Run the Pre-Upgrade Information Tool:
SQL> @utlu111i.sql
8. Turn off the spooling of the script results to the log file and check the output of the Pre-Upgrade
Information Tool in upgrade_info.log.

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


Practice 1-2: Overview

In the first part of this practice, you conduct a pre-upgrade


analysis.

1 - 13 Copyright 2007, Oracle. All rights reserved.

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


STARTUP UPGRADE

STARTUP UPGRADE suppresses normal upgrade errors:


Only real errors are spooled.
Automatically handles setting of system parameters
that can otherwise cause problems during upgrade
Turns off job queues
Disables system triggers
Allows AS SYSDBA connections only
Replaces STARTUP MIGRATE in Oracle Database 9i,
Release 2
To upgrade, start up the database as follows:

SQL> STARTUP UPGRADE

1 - 14 Copyright 2007, Oracle. All rights reserved.

STARTUP UPGRADE
STARTUP UPGRADE enables you to open a database based on an earlier Oracle Database release. It
also restricts logons to AS SYSDBA sessions, disables system triggers, and performs additional
operations that prepare the environment for the upgrade (some of which are listed in the slide).
To upgrade the candidate database, follow the directions below:
1. Set the ORACLE_SID correctly.
The oratab file should point to your Oracle Database 11g Oracle home. The following
environment variables point to the Oracle Database 11g directories:
ORACLE_HOME
PATH
2. Log in to the system as the owner of the Oracle Database 11g Oracle home directory.
3. At system prompt, change to the ORACLE_HOME/rdbms/admin directory and SQL*Plus.
4. Connect to the database instance as a user with SYSDBA privileges.
5. Start up the instance by issuing the following command:
SQL> STARTUP UPGRADE

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


Upgrade Performance Enhancement

Parallel recompilation of invalid PL/SQL database objects


on multiprocessor CPUs:
utlrp.sql can now exploit multiple CPUs to speed up
the time required to recompile any stored PL/SQL and
Java code.
UTL_RECOMP automatically determines the level of
parallelism based on CPU_COUNT and
PARALLEL_THREADS_PER_CPU.

1 - 15 Copyright 2007, Oracle. All rights reserved.

Upgrade Performance Enhancement


The script is a wrapper based on the UTL_RECOMP package. UTL_RECOMP provides a more general
recompilation interface, including options to recompile objects in a single schema. For details, see
the documentation for UTL_RECOMP.
By default, this script invokes the utlprp.sql script with 0 as the degree of parallelism for
recompilation. This means that UTL_RECOMP automatically determines the appropriate level of
parallelism based on the Oracle CPU_COUNT and PARALLEL_THREADS_PER_CPU parameters. If
the parameter is set to 1, sequential recompilation is used.

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


Post-Upgrade Status Tool

Run utlu111s.sql to display the results of the upgrade:


Error logging now provides more information per
component.
Reviews the status of each component and lists the
elapsed time
Provides information about invalid or incorrect
component upgrades
Run this tool after the upgrade completes, to see errors
and check the status of the components.

1 - 16 Copyright 2007, Oracle. All rights reserved.

Post-Upgrade Status Tool


The Post-Upgrade Status Tool provides a summary of the upgrade at the end of the spool log. It
displays the status of the database components in the upgraded database and the time required to
complete each component upgrade. Any errors that occur during the upgrade are listed with each
component and must be addressed.
Run utlu111s.sql to display the results of the upgrade.

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


1 - 17 Copyright 2007, Oracle. All rights reserved.

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


Upgrade Process

1 - 18 Copyright 2007, Oracle. All rights reserved.

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


Prepare to Upgrade

1. Become familiar with the features of Oracle Database


11g, Release 1.
2. Determine the upgrade path.
3. Choose an upgrade method.
4. Choose an OFA-compliant Oracle home directory.
5. Prepare a backup and recovery strategy.
6. Develop a test plan to test your database, applications,
and reports.

1 - 19 Copyright 2007, Oracle. All rights reserved.

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


Oracle Database 11g Release 1: Upgrade Paths

Direct upgrade to 11g is supported from 9.2.0.4 or


higher, 10.1.0.2 or higher, and 10.2.0.1 or higher.
If you are not at one of these versions, you need to
perform a "double-hop" upgrade.
Examples
7.3.4 9.2.0.8 11.1
8.1.7.4 9.2.0.8 11.1

1 - 20 Copyright 2007, Oracle. All rights reserved.

Oracle Database 11g Release 1 Upgrade Paths


The path that you must take to upgrade to Oracle Database 11g, Release 1 depends on the release
number of your current database. It might not be possible to upgrade directly from the current
version of the Oracle Database to the latest version. Depending on your current release, you might be
required to upgrade through one or more intermediate releases to upgrade to Oracle Database 11g,
Release 1.
For example, if the current database is running release 8.1.6, follow these steps:
1. Upgrade release 8.1.6 to release 8.1.7 by using the instructions in the Oracle8i Database
Migration, Release 3 (8.1.7).
2. Upgrade release 8.1.7 to release 9.2.0.8 by using the instructions in the Oracle9i Database
Migration, Release 2 (9.2).
3. Upgrade release 9.2.0.8 to Oracle Database 11g, Release 1 by using the instructions in this
lesson.

Oracle Database 11g: New Features for Administrators 1 - 20


Choose an Upgrade Method

Database Upgrade Assistant (DBUA)


Automated GUI tool that interactively steps the user
through the upgrade process and configures the
database to run with Oracle Database 11g, Release 1
Manual upgrade
Use SQL*Plus to perform any necessary actions to
prepare for the upgrade, run the upgrade scripts, and
analyze the upgrade results.
Export and Import utilities
Use Data Pump or original Export/Import.
CREATE TABLE AS SELECT statement

1 - 21 Copyright 2007, Oracle. All rights reserved.

Choose an Upgrade Method


Oracle Database 11g, Release 1 supports the following tools and methods for upgrading a database to
the new release:
Database Upgrade Assistant (DBUA) provides a graphical user interface (GUI) that guides you
through the upgrade of a database. The DBUA can be launched during installation with Oracle
Universal Installer, or you can launch the DBUA as a stand-alone tool at any time in the future.
The DBUA is the recommended method for performing a major release upgrade or patch release
upgrade.
Manual upgrade can be performed using SQL scripts and utilities to provide a command-line
upgrade of a database.
Export and Import utilities: Use the Oracle Data Pump Export and Import utilities, available
as of Oracle Database 10g, Release 1 (10.1), or the original Export and Import utilities to
perform a full or partial export from your database, followed by a full or partial import into a
new Oracle Database 11g, Release 1 database. Export/Import can copy a subset of the data,
leaving the database unchanged.
CREATE TABLE AS SELECT statement copies data from a database into a new Oracle
Database 11g, Release 1 database. Data copying can copy a subset of the data, leaving the
database unchanged.

Oracle Database 11g: New Features for Administrators 1 - 21


Database Upgrade Assistant:
Advantages and Disadvantages

Advantages
Automates all tasks
Performs both release and patch set upgrades
Supports RAC, Single Instance, and ASM
Informs the user and fixes upgrade prerequisites
Automatically reports errors found in spool logs
Provides complete HTML report of the upgrade process
Command-line interface allows ISVs to automate
Disadvantages
Offers less control over individual upgrade steps

1 - 22 Copyright 2007, Oracle. All rights reserved.

Database Upgrade Assistant: Advantages and Disadvantages


The Database Upgrade Assistant (DBUA) guides you through the upgrade process and configures a
database for the new release. The DBUA automates the upgrade process and makes appropriate
recommendations for configuration options such as tablespaces and redo logs. While the upgrade is
running, the DBUA shows the upgrade progress for each component. The DBUA writes detailed
trace and log files, and produces a complete HTML report for later reference. To enhance security,
the DBUA automatically locks new user accounts in the upgraded database. The DBUA then
proceeds to create new configuration files (initialization parameter and listener files) in the new
Oracle home.
If the DBA requires more control over the individual steps in the upgrade process, a manual upgrade
is still possible. Usually, however, the manual upgrade method is more error prone, is harder to
automate, and involves a greater amount of work than upgrading with the DBUA.

Oracle Database 11g: New Features for Administrators 1 - 22


Sample Test Plan

Use Enterprise Manager to make a clone of your


production system.
Upgrade the test database to the latest version.
Update COMPATIBLE to the latest version.
Run your applications, reports, and legacy systems.
Ensure adequate performance by comparing metrics
gathered before and after the upgrade.
Tune queries or problem SQL statements.
Update any necessary database parameters.

1 - 23 Copyright 2007, Oracle. All rights reserved.

Sample Test Plan


A series of carefully designed tests is required to validate all stages of the upgrade process. Executed
rigorously and completed successfully, these tests ensure that the process of upgrading the
production database is well understood, predictable, and successful. Perform as much testing as
possible before upgrading the production database. Do not underestimate the importance of a test
program.
Testing the upgraded database is just as important as testing the upgrade process. Test the newly
upgraded test database with existing applications to verify that they operate properly with a new
Oracle database. You might also want to test enhanced functions by adding the available Oracle
Database features. However, first make sure that the applications operate in the same manner as they
did in the current database.

Oracle Database 11g: New Features for Administrators 1 - 23


Database Upgrade Assistant

1 - 24 Copyright 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 1 - 24


Database Upgrade Assistant (DBUA)

The DBUA is a GUI and command-line tool for


performing database upgrades.
Uses a wizard interface:
Automates the upgrade process
Simplifies detecting and handling of upgrade issues
Supported releases for 11g:
9.2, 10.1 and 10.2
Patchset upgrades:
Supported: 10.2.0.3 and later
Support the following database types:
Single instance
Real Application Clusters
Automatic Storage Management

1 - 25 Copyright 2007, Oracle. All rights reserved.

Database Upgrade Assistant (DBUA)


The Database Upgrade Assistant (DBUA) guides you through the upgrade process and configures a
database for the new release. The DBUA automates the upgrade process and makes appropriate
recommendations for configuration options such as tablespaces and redo logs.
The DBUA can be used to upgrade databases that were created with any edition of the Oracle
Database software, including the Express Edition (XE) databases. The DBUA supports the following
versions of Oracle Database for upgrading to Oracle Database 11g, Release 1:
Oracle9i, Release 2 (9.2.0.4) and later 9i releases
Oracle Database 10g, Release 1 (10.1)
Oracle Database 10g, Release 2 (10.2)
If your database version is not in this list, you must first upgrade to the closest release listed and then
upgrade to Oracle Database 11g, Release 1.
The Database Upgrade Assistant is fully compliant with Oracle RAC environments. In RAC
environments, the DBUA upgrades all database and configuration files on all nodes in the cluster.
The DBUA supports upgrades of databases that use Automatic Storage Management (ASM). If an
ASM instance is detected, you have the choice of updating both the database and the ASM, or
updating only the ASM instance.
The Database Upgrade Assistant supports a silent mode of operation in which no user interface is
presented to the user. Silent mode enables you to use a single statement for the upgrade.
Oracle Database 11g: New Features for Administrators 1 - 25
Key DBUA Features

Recoverability
Performs a backup of the database before upgrade
Can restore the database after upgrade (if needed)
Runs all necessary scripts to perform the upgrade
Displays upgrade progress at a component level
Configuration checks
Automatically makes appropriate adjustments to the
initialization parameters
Checks for adequate resources such as SYSTEM
tablespace size, rollback segment size, and redo log size
Checks disk space for auto-extended data files
Creates mandatory SYSAUX tablespace

1 - 26 Copyright 2007, Oracle. All rights reserved.

Key DBUA Features


Before starting the upgrade process, Oracle Corporation strongly recommends that you back up your
existing database, although the DBUA can perform a backup during the pre-upgrade stage. If you use
the DBUA to back up your database, it creates a copy of all your database files in the directory that
you specify. The DBUA performs this cold backup automatically after it shuts down the database and
before it begins performing the upgrade procedure. However, the cold backup does not compress
your database files, and the backup directory must be a valid file system path. In addition, the DBUA
creates a batch file in the specified directory. You can use this batch file to restore the database files
if needed.
During the upgrade, the DBUA automatically modifies or creates new required tablespaces and
invokes the appropriate upgrade scripts. While the upgrade is running, DBUA shows the upgrade
progress for each component. The DBUA then creates new configuration files (parameter and
listener files) in the new Oracle home.
The DBUA performs the following checks before the upgrade:
Invalid user accounts or roles
Invalid data types or invalid objects
De-supported character sets
Adequate resources (including rollback segments, tablespaces, and free disk space)
Missing SQL scripts needed for the upgrade
Listener running (if Oracle EM Database Control upgrade or configuration is requested)
The DBUA provides a comprehensive summary of the pre-upgrade checks when finished.
Oracle Database 11g: New Features for Administrators 1 - 26
Key DBUA Features

Configuration files
Creates init.ora and spfile in the new ORACLE_HOME
Updates network configurations
Uses OFA-compliant locations
Updates database information on OID
Oracle Enterprise Manager
DBCA allows you to set up and configure EM DB Control.
DBCA allows you to register a database with EM Grid
Control.
If EM is in use, DBCA enables you to upgrade the EM
catalog and make the necessary configuration changes.
Logging and tracing
Writes detailed trace and logging files
(ORACLE_BASE/cfgtoollogs/dbua/<sid>/upgradeNN)

1 - 27 Copyright 2007, Oracle. All rights reserved.

Key DBUA Features (continued)


During the upgrade, the DBUA automatically modifies or creates new init.ora and spfile in the
new ORACLE_HOME directory. In addition, the DBUA updates the network configurations, creates
the required tablespaces, and invokes the appropriate upgrade scripts. While the upgrade is running,
the DBUA shows the upgrade progress for each component. The DBUA writes detailed trace and log
files in $ORACLE_BASE/cfgtoollogs/dbua/<sid>/upgradeNN and produces a complete
HTML report for later reference.

Oracle Database 11g: New Features for Administrators 1 - 27


Key DBUA Features

Minimizing down time


Speeds up upgrade by disabling archiving
Recompiles packages in parallel
Does not require user interaction after upgrade starts
Security features
Locks new users in the upgraded database
Real Application Clusters
Upgrades all nodes
Upgrades all configuration files

1 - 28 Copyright 2007, Oracle. All rights reserved.

Key DBUA Features (continued)


After completing the pre-upgrade steps, the DBUA automatically archives redo logs and disables
archiving during the upgrade phase.
To enhance security, the DBUA automatically locks new user accounts in the upgraded database.
The DBUA then proceeds to create new configuration files (initialization parameter and listener
files) in the new Oracle home.
The Database Upgrade Assistant is fully compliant with Oracle RAC environments. In RAC
environments, the DBUA upgrades all database and configuration files on all nodes in the cluster.

Oracle Database 11g: New Features for Administrators 1 - 28


Command-Line Syntax

Silent mode run


$ dbua silent dbName <Oracle database>
Backup location
$ dbua backupLocation
Custom scripts
$ dbua -postUpgradeScripts
Initialization parameters
$ dbua initParam
Help
$ dbua -help
EM configuration
$ dbua emConfiguration

1 - 29 Copyright 2007, Oracle. All rights reserved.

Command-Line Syntax
When invoked with the -silent command line option, the DBUA operates in silent mode. In the
silent mode, the DBUA does not present a user interface. It also writes any messages (including
information, errors, and warnings) to a log file in
ORACLE_HOME/cfgtoollogs/dbua/SID/upgraden, where n is the number of upgrades that the
DBUA has performed as of this upgrade.
For example, the following command upgrades a database named ORCL in the silent mode:
$ dbua -silent -dbName ORCL &
Here is a list of important options that you can use:
-backupLocation directory specifies a directory to back up your database before the
upgrade starts.
-postUpgradeScripts script [, script ] specifies a comma-delimited list of SQL
scripts. Specify complete path names. The scripts are executed at the end of the upgrade.
-initParam parameter=value [, parameter=value ] specifies a comma-delimited list
of initialization parameter values of the form name=value.
-emConfiguration {CENTRAL|LOCAL|ALL|NOBACKUP|NOEMAIL|NONE}specifies the
Oracle Enterprise Manager management options.
Note: For more information about these options, see the Oracle Database Upgrade Guide 11g.

Oracle Database 11g: New Features for Administrators 1 - 29


Using DBUA to Upgrade Your Database

1 - 30 Copyright 2007, Oracle. All rights reserved.

Using DBUA to Upgrade Your Database


To upgrade a database by using the DBUA graphical user interface:
On Linux or UNIX platforms, enter the dbua command at system prompt in the Oracle Database
11g, Release 1 environment. The DBUA Welcome screen appears.
Click Next.
If an ASM instance is detected on the system, the Upgrade Operations page provides you with the
options to upgrade a database or an ASM instance. If no ASM instance is detected, the Databases
screen appears.
At the Upgrade Operations page, select Upgrade a Database. This operation upgrades a database to
Oracle Database 11g, Release 1.
Oracle recommends that you upgrade the database and ASM in separate DBUA sessions in separate
Oracle homes.
Click Next.

Oracle Database 11g: New Features for Administrators 1 - 30


Choose Database to Upgrade
and Diagnostic Destination

1 - 31 Copyright 2007, Oracle. All rights reserved.

Choose Database to Upgrade and Diagnostic Destination


The Databases screen appears.
Select the database that you want to upgrade from the Available Databases table.
You can select only one database at a time. If you do not see the database that you want, make sure
that an entry with the database name exists in the oratab file in the etc directory.
If you are running the DBUA from a user account that does not have SYSDBA privileges, you must
enter the user name and password credentials to enable SYSDBA privileges for the selected database.
Click Next.
The DBUA analyzes the database, performing the following pre-upgrade checks and displaying
warnings as necessary:
Redo log files whose size is less than 4 MB. If such files are found, the DBUA gives the option
to drop or create new redo log files.
Obsolete or deprecated initialization parameters
When the DBUA finishes its checks, the Diagnostic Destination screen appears.
Perform one of the following:
Accept the default location for your diagnostic destination.
Enter the full path to a different diagnostic destination in the Diagnostic Destination field. Click
Browse to select a diagnostic destination.
Click Next.
Oracle Database 11g: New Features for Administrators 1 - 31
Moving Database Files

1 - 32 Copyright 2007, Oracle. All rights reserved.

Moving Database Files


If you are upgrading a single-instance database, the Move Database Files page appears. However, if
you are upgrading an Oracle Real Application Clusters database, the Move Database Files page does
not appear.
Select one of the following options:
Do Not Move Database Files as Part of Upgrade
Move Database Files during Upgrade
If you choose to move database files, you must also select one of the following:
File System: Your database files are stored on the host file system.
Automatic Storage Management (ASM): Your database files are stored on the ASM storage,
which must already exist on your system. If you do not have an ASM instance, you can create
one using DBCA and then restart the DBUA.
Click Next.

Oracle Database 11g: New Features for Administrators 1 - 32


Database File Locations

1 - 33 Copyright 2007, Oracle. All rights reserved.

Database File Locations


The Database File Locations screen appears.
Select one of the following options:
Use Common Location for All Database Files: If you choose to have all of your database files in
one location, you must also perform one of the following:
- Accept the default location for your database files.
- Enter the full path to a different location in the Database File Locations field.
- Click Browse and select a different location for your database files.
Use Oracle-Managed Files: If you choose to use Oracle-Managed Files for your database files,
you must also perform one of the following:
- Accept the default database area.
- Enter the full path to a different database area in the Database Area field.
- Click Browse and select a different database area.
Use a Mapping File to Specify Location of Database Files: This option enables you to specify
different locations for your database files. A sample mapping file is available in the logging
location. You can edit the property values of the mapping file to specify a different location for
each database file.
Click Next.

Oracle Database 11g: New Features for Administrators 1 - 33


Recovery Configuration

1 - 34 Copyright 2007, Oracle. All rights reserved.

Recovery Configuration
The Recovery Configuration page enables you to designate a Flash Recovery Area for your database.
If you selected Move Database Files during Upgrade, or if an Oracle Express Edition database is
being upgraded to Oracle Enterprise Edition, then a Flash Recovery Area must be configured. If a
Flash Recovery Area is already configured, the current settings are retained but the screen is
displayed to enable you to override these values.
Click Next.

Oracle Database 11g: New Features for Administrators 1 - 34


Management Options and Database Credentials

1 - 35 Copyright 2007, Oracle. All rights reserved.

Management Options and Database Credentials


If no other database is already being monitored with Enterprise Manager, the Management Options
page appears. On this page, you have the option of setting up your database so that it can be managed
with Enterprise Manager.
Before you can register the database with Oracle Enterprise Manager Grid Control, an Oracle
Enterprise Manager Agent must be configured on the host computer.
To set up your database to be managed with Enterprise Manager, select Configure the Database
with Enterprise Manager and then select one of the proposed options.
Click Next. The Database Credentials page appears.
Choose one of the proposed options and click Next.

Oracle Database 11g: New Features for Administrators 1 - 35


Network Configuration

1 - 36 Copyright 2007, Oracle. All rights reserved.

Network Configuration
If the DBUA detects that multiple listeners are configured, the Network Configuration for the
database page appears. This page has two tabs. The Listeners tab is displayed if you have more than
one listener. The Directory Service tab appears if you have the directory services configured.
On the Listeners tab, select one of the following options:
Register this database with all the listeners
Register this database with selected listeners only
If you choose to register selected listeners only, you must select the listeners that you want from the
Available Listeners list, and then use the arrow buttons to move them to the Selected Listeners list. If
you want to register your database with a directory service, click the Directory Service tab.
On the Directory Service tab, select one of the following options:
Yes, register the database: Selecting this option enables client computers to connect to this
database without a local name file (tnsnames.ora) and also enables them to use the Oracle
Enterprise User Security feature.
No, dont register the database
If you choose to register the database, you must also provide a user distinguished name (DN) in the
User DN field and a password for that user in the Password field. An Oracle Wallet is created as part
of database registration. It contains credentials suitable for password authentication between this
database and the directory service. Enter a password in both the Wallet Password field and the
Confirm Password field. Then click Next.
Oracle Database 11g: New Features for Administrators 1 - 36
Recompile Invalid Objects

1 - 37 Copyright 2007, Oracle. All rights reserved.

Recompile Invalid Objects


The Recompile Invalid Objects page appears.
Select Recompile invalid objects at the end of upgrade if you want the DBUA to recompile all
invalid PL/SQL modules after the upgrade is complete. This ensures that you do not experience any
performance issues when you begin using your newly upgraded database.
If you have multiple CPUs, you can reduce the time it takes to perform this task by taking advantage
of parallel processing on your available CPUs. If you have multiple CPUs, the DBUA automatically
adds an additional section to the Recompile Invalid Objects page and automatically determines the
number of CPUs you have available.
The DBUA also provides a recommended degree of parallelism, which determines how many
parallel processes are used to recompile your invalid PL/SQL modules. Specifically, the DBUA sets
the degree of parallelism to one less than the number of CPUs you have available. You can adjust
this default value by selecting a new value from the Degree of Parallelism list.
Select Turn off Archiving and Flashback logging, for the duration of upgrade to reduce the time
required to complete the upgrade.
If the database is in the ARCHIVELOG or flashback logging mode, the DBUA gives you the choice
of turning them off for the duration of the upgrade. If you choose this option, Oracle recommends
that you perform an offline backup immediately after the upgrade.
Click Next.
Oracle Database 11g: New Features for Administrators 1 - 37
Database Backup and Space Checks

1 - 38 Copyright 2007, Oracle. All rights reserved.

Database Backup and Space Checks


The Backup page appears. Select Backup database if you want the DBUA to back up your
database. Oracle strongly recommends that you back up your database before starting the upgrade. If
errors occur during the upgrade, you might be required to restore the database from the backup.
If you use the DBUA to back up your database, it makes a copy of all your database files in the
directory that you specify in the Backup Directory field. The DBUA performs this cold backup
automatically after it shuts down the database, and before it begins performing the upgrade
procedure. The cold backup does not compress your database files and the backup directory must be
a valid file system path. You cannot specify a raw device for the cold backup files.
In addition, the DBUA creates a batch file in the specified directory. You can use this batch file to
restore the database files:
On Windows operating systems, the file is db_name_restore.bat.
On Linux and UNIX platforms, the file is db_name_restore.sh.
If you choose not to use the DBUA for your backup, Oracle assumes that you have already backed up
your database using your own backup procedures. Click Next.
Note: If you decide to use the DBUA to back up your database, the DBUA checks that you have
enough space before the backup is taken.

Oracle Database 11g: New Features for Administrators 1 - 38


Database Upgrade Summary

1 - 39 Copyright 2007, Oracle. All rights reserved.

Database Upgrade Summary


The Summary page appears. It shows the following information about the upgrade before it starts:
Name, version, and Oracle home of the old and new databases
Database backup location, available space, and space required
Warnings ignored
Database components to be upgraded
Initialization parameter changes
Database file locations
Listener registration
Check all of the specifications. Then perform one of the following:
If anything is incorrect, click Back repeatedly until you reach the screen where you can
correct it.
Click Finish if everything is correct.

Oracle Database 11g: New Features for Administrators 1 - 39


Upgrade Progress and Results

1 - 40 Copyright 2007, Oracle. All rights reserved.

Upgrade Progress and Results


The Progress screen appears, and the DBUA begins the upgrade.
You might encounter error messages with the Ignore and Abort choices. If other errors appear, you
must address them accordingly. If an error is severe and cannot be handled during the upgrade, you
have the following choices:
Click Ignore to ignore the error and proceed with the upgrade. You can fix the problem, restart
the DBUA, and complete the skipped steps.
Click Abort to terminate the upgrade process. If a database backup was taken by the DBUA, it
asks if you want to restore the database. After the database has been restored, you must correct
the cause of the error and restart the DBUA to perform the upgrade again. If you do not want to
restore the database, the DBUA leaves the database in its present state so that you can proceed
with a manual upgrade.
After the upgrade has completed, the following message is displayed:
Upgrade is complete. Click OK to see the results of the upgrade.
When you click OK, the Upgrade Results screen appears.
The Upgrade Results screen displays a description of the original and upgraded databases, and the
changes made to the initialization parameters. The screen also shows the directory where various log
files are stored after the upgrade. You can examine these log files to obtain more details about the
upgrade process.
Click Restore Database if you are not satisfied with the upgrade results.
Oracle Database 11g: New Features for Administrators 1 - 40
Practice 1-2: Overview

In the second part of this practice, you upgrade your ASM


instance to an Oracle Database 11g environment.

1 - 41 Copyright 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 1 - 41


You are now ready to use
Oracle Database 11g, Release 1!

Perform any required post-upgrade steps.


Make additional post-upgrade adjustments to the
initialization parameters.
Upgrade the Recovery Catalog.
Test your applications and tune performance.
Set the COMPATIBLE initialization parameter to 11.1 to
make full use of the Oracle Database 11g, Release 1
features.
10.0.0 is the minimum compatibility required for 11.1.

1 - 42 Copyright 2007, Oracle. All rights reserved.

You are now ready to use Oracle Database 11g, Release 1!


After you have upgraded your database and before you can consider the database operational,
you must complete some post-upgrade tasks regardless of whether you performed the upgrade either
manually or by using the DBUA. Some of the more common tasks include:
Update environment variables (Linux and UNIX systems only)
Adjust initialization parameters as needed
Upgrade the Recovery Catalog
Test your applications and tune performance
Upgrade the statistics tables created by the DBMS_STATS package
Enable Oracle Database Vault
Upgrade the TIMESTAMP data
Use the latest Time Zone file for clients

Oracle Database 11g: New Features for Administrators 1 - 42


Deprecated Features in
Oracle Database 11g, Release 1

Oracle Ultra Search


Java Development Kit (JDK) 1.4
CTXXPATH index

1 - 43 Copyright 2007, Oracle. All rights reserved.

Deprecated Features in Oracle Database 11g, Release 1


The slide lists the Oracle Database features that are deprecated in Oracle Database 11g, Release 1.
Although they are supported in this release for backward compatibility, Oracle recommends that you
migrate away from these deprecated features:
Oracle Ultra Search
Java Development Kit (JDK) 1.4: Oracle recommends that you use JDK 5.0; however, JDK 1.5
is also fully supported.
CTXXPATH index: Oracle recommends that you use XMLIndex instead.

Oracle Database 11g: New Features for Administrators 1 - 43


Important Initialization Parameter Changes

USER_DUMP_DEST
BACKGROUND_DUMP_DEST DIAGNOSTIC_DEST
CORE_DUMP_DEST
UNDO_MANAGEMENT not set implies AUTO mode.
To migrate to automatic undo management:
1. Set UNDO_MANAGEMENT=MANUAL.
2. Execute your workload.
3. Execute the DBMS_UNDO_ADV.RBU_MIGRATION function.
4. Create an undo tablespace based on previous size result.
5. Set UNDO_MANAGEMENT=AUTO.

1 - 44 Copyright 2007, Oracle. All rights reserved.

Important Initialization Parameter Changes


The DIAGNOSTIC_DEST initialization parameter replaces the USER_DUMP_DEST,
BACKGROUND_DUMP_DEST, and CORE_DUMP_DEST parameters. Starting with Oracle Database
11g, the default location for all trace information is defined by DIAGNOSTIC_DEST, which defaults
to $ORACLE_BASE/diag. Old parameters are ignored if specified.
For more information about diagnostics, refer to the lesson titled Diagnosability Enhancements.
A newly installed Oracle Database 11g instance defaults to automatic undo management mode, and,
if the database is created with the DBCA, an undo tablespace is automatically created. A null value
for the UNDO_MANAGEMENT initialization parameter now defaults to automatic undo management;
in previous releases, it defaulted to manual undo management mode. You must therefore use caution
when upgrading a previous release to Oracle Database 11g.
Note: The CONTROL_MANAGEMENT_PACK_ACCESS initialization parameter specifies the Server
Manageability Packs that should be active. The following packs are available:
The DIAGNOSTIC pack includes AWR, ADDM, and so on.
The TUNING pack includes SQL Tuning Advisor, SQL Access Advisor, and so on.
A license for DIAGNOSTIC is required to enable the TUNING pack.
Possible values for this parameter are NONE, DIAGNOSTIC, and DIAGNOSTIC+TUNING (default).

Oracle Database 11g: New Features for Administrators 1 - 44


Important Initialization Parameter Changes (continued)
To migrate to automatic undo management, perform the following steps:
1. Set UNDO_MANAGEMENT=MANUAL.
2. Start the instance again and run through a standard business cycle to obtain a representative
workload.
3. After the standard business cycle completes, run the following function to collect the undo
tablespace size:
DECLARE
utbsiz_in_MB NUMBER;
BEGIN
utbsiz_in_MB := DBMS_UNDO_ADV.RBU_MIGRATION;
end;
/
This function runs a PL/SQL procedure that provides information about how to size your new undo
tablespace based on the configuration, and use of the rollback segments in your system.
The function returns the sizing information directly.
4. Create an undo tablespace of the required size and turn on automatic undo management by
setting UNDO_MANAGEMENT=AUTO, or by removing the parameter.
Note: For RAC configurations, repeat these steps on all instances.

Oracle Database 11g: New Features for Administrators 1 - 45


Direct NFS Client: Overview

Oracle Database 10g Oracle Database 11g


Optional generic
configuration
parameters
Oracle Oracle
RDBMS RDBMS
kernel kernel
Specific
configuration
parameters DBA
Specific Specific
kernel kernel
NFS driver NFS driver

Variations across platforms


Many parameters to tune
NAS NAS
Ease of NFS configuration
Storage Fewer parameters to tune
Storage
(NFS V3)

1 - 46 Copyright 2007, Oracle. All rights reserved.

Direct NFS Client: Overview


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

1 Mount all expected mount points using kernel NFS driver.

2 (Optional) Create an oranfstab file.

cp libodm11.so libodm11.so_stub
3 ln -s libnfsodm11.so libodm11.so

Mount points lookup order


server: MyDataServer1
$ORACLE_HOME/dbs/oranfstab Load balancing path: 132.34.35.12
and path: 132.34.35.13
failover export: /vol/oradata1 mount: /mnt/oradata1
/etc/oranfstab

/etc/mtab

1 - 47 Copyright 2007, Oracle. All rights reserved.

Direct NFS Configuration


By default, Direct NFS attempts to serve mount entries found in /etc/mtab. No other configuration
is required. You can optionally use oranfstab to specify additional Oracle-specific options to
Direct NFS. For example, you can use oranfstab to specify additional paths for a mount point as
shown in the example in the slide.
When oranfstab is placed in $ORACLE_HOME/dbs, its entries are specific to a single database.
However, when oranfstab is placed in /etc, it is global to all Oracle databases and thus, can
contain mount points for all Oracle databases.
Direct NFS looks for the mount point entries in the following order:
$ORACLE_HOME/dbs/oranfstab, /etc/oranfstab, and /etc/mtab. It uses the first matched
entry as the mount point.
In all cases, Oracle requires that mount points be mounted by the kernel NFS system even when
being served through Direct NFS. Oracle verifies kernel NFS mounts by cross-checking entries in
oranfstab with the operating system NFS mount points. If a mismatch exists, Direct NFS logs an
informational message and does not serve the NFS server.

Oracle Database 11g: New Features for Administrators 1 - 47


Direct NFS Configuration (continued)
Complete the following procedure to enable Direct NFS:
1. Make sure that NFS mount points are mounted by your kernel NFS client. The file systems to be
used through ODM NFS should be mounted and available over regular NFS mounts for Oracle
to retrieve certain bootstrapping information. The mount options that are used in mounting the
file systems are not relevant.
2. (Optional) Create an oranfstab file with the following attributes for each NFS server to be
accessed using Direct NFS:
- Server: The NFS server name
- Path: Up to four network paths to the NFS server, specified either by IP address or by name,
as displayed using the ifconfig command. The Direct NFS client performs load
balancing across all specified paths. If a specified path fails, Direct NFS reissues I/Os over
any remaining paths.
- Export: The exported path from the NFS server
- Mount: The local mount point for the NFS server
3. Oracle Database uses the ODM library, libnfsodm10.so, to enable Direct NFS. To replace
this standard ODM library with the ODM NFS library, complete the following steps:
- Change directory to $ORACLE_HOME/lib.
- Enter the following commands:
cp libodm11.so libodm11.so_stub
ln -s libnfsodm11.so libodm11.so
Use one of the following methods to disable the Direct NFS client:
Remove the oranfstab file.
Restore the stub libodm11.so file by reversing the process you completed in step 3.
Remove the specific NFS server or export paths in the oranfstab file.
Notes
If you remove an NFS path that the Oracle Database is using, you must restart the database for
the change to be effective.
If Oracle Database is unable to open an NFS server using Direct NFS, it uses the platform
operating system kernel NFS client. In this case, the kernel NFS mount options must be set up
correctly. Additionally, an informational message is logged into the Oracle alert and trace files
indicating that Direct NFS could not be established.
With the current ODM architecture, there can be only one active ODM implementation for each
instance at any given time. Using NFS ODM in an instance precludes any other ODM
implementation.
The Oracle files resident on the NFS server that are served by the Direct NFS Client are also
accessible through the operating system kernel NFS client. The usual considerations for
maintaining integrity of the Oracle files apply in this situation.

Oracle Database 11g: New Features for Administrators 1 - 48


Monitoring Direct NFS

SVR_ID V$DNFS_FILES

Join column

V$DNFS_SERVERS PNUM V$DNFS_STATS

SVR_ID V$DNFS_CHANNELS

1 - 49 Copyright 2007, Oracle. All rights reserved.

Monitoring Direct NFS


Use the following views for Direct NFS management:
V$DNFS_SERVERS: Shows a table of servers accessed using Direct NFS
V$DNFS_FILES: Shows a table of files currently open using Direct NFS
V$DNFS_CHANNELS: Shows a table of open network paths (or channels) to servers for which
Direct NFS is providing files
V$DNFS_STATS: Shows a table of performance statistics for Direct NFS

Oracle Database 11g: New Features for Administrators 1 - 49


Hot Patching: Overview

For a bug fix or diagnostic patch on a running Oracle


instance, hot patching provides the ability to do the
following:
Install
Enable
Disable

1 - 50 Copyright 2007, Oracle. All rights reserved.

Hot Patching: Overview


Hot patching provides the ability to install, enable, and disable a bug fix or diagnostic patch on a live,
running Oracle instance. Using hot patching is the recommended solution for avoiding down time
when applying hot patches. Oracle provides the capability to do hot patching with any Oracle
database using the opatch command-line utility. Hot patches can be provided when the changed
code is small in scope and complexity (for example, with diagnostic patches or small bug fixes).

Oracle Database 11g: New Features for Administrators 1 - 50


Installing a Hot Patch

Applying a hot patch does not require instance


shutdown, relinking of the Oracle binary, or instance
restart.
OPatch can be used to install or uninstall a hot patch.
OPatch detects conflicts between two hot patches, as
well as between a hot patch and a conventional patch.

1 - 51 Copyright 2007, Oracle. All rights reserved.

Installing a Hot Patch


Unlike traditional patching mechanisms, applying a hot patch does not require instance shutdown or
restart.
Similar to traditional patching, you can use OPatch to install a hot patch.
You can determine whether a patch is a hot patch by using the following command:
opatch query -is_online_patch <patch location> or
opatch query <patch location> -all
Note: The patched code is shipped as a dynamic/shared library, which is then mapped into memory
by each Oracle process.

Oracle Database 11g: New Features for Administrators 1 - 51


Benefits of Hot Patching

No down time and no interruption of business


Extremely fast install and uninstall times
Integrated with OPatch:
Conflict detection
Listed in patch inventory
Works in RAC environment
Although the on-disk Oracle binary is unchanged, hot
patches persist across instance shutdown and startup.

1 - 52 Copyright 2007, Oracle. All rights reserved.

Benefits of Hot Patching


You do not have to shut down your database instance while you apply the hot patch. Unlike
conventional patching, hot patching is extremely fast to install and uninstall. Because hot patching
uses OPatch, you get all the benefits that you already have with conventional patching that uses
OPatch. It does not matter how long or how many times you shut down your databasea hot patch
always persists across instance shutdown and startup.

Oracle Database 11g: New Features for Administrators 1 - 52


Conventional Patching and Hot Patching

Conventional Patches Hot Patches


Require down time to apply Do not require down time to apply
or remove or remove
Installed and uninstalled Installed and uninstalled
via OPatch via OPatch
Persist across instance startup Persist across instance startup
and shutdown and shutdown
Take several minutes to install Take only a few seconds to install
or uninstall or uninstall

1 - 53 Copyright 2007, Oracle. All rights reserved.

Conventional Patching and Hot Patching


Conventional patching basically requires a shutdown of your database instance.
Hot patching does not require any down time. Applications can keep running while you install a hot
patch. Similarly, hot patches that have been installed can be uninstalled with no down time.

Oracle Database 11g: New Features for Administrators 1 - 53


Hot Patching Considerations

Hot patches may not be available on all platforms. They


are currently available on:
Linux x86
Linux x86-64
Solaris SPARC64
Some extra memory is consumed.
Exact amount depends on:
Size of patch
Number of concurrently running Oracle processes
Minimum amount of memory: approximately one OS page
per running Oracle process

1 - 54 Copyright 2007, Oracle. All rights reserved.

Hot Patching Considerations


One operating system (OS) page is typically 4 KB on Linux x86 and 8 KB on Solaris SPARC64.
With an average of approximately one thousand Oracle processes running at the same time, this
represents around 4 MB of extra memory for a small hot patch.

Oracle Database 11g: New Features for Administrators 1 - 54


Hot Patching Considerations

There may be a small delay (a few seconds) before


every Oracle process installs or uninstalls a hot patch.
Not all bug fixes and diagnostic patches are available
as a hot patch.
Use hot patches in situations when down time is not
feasible.
When down time is possible, you should install all
relevant bug fixes as conventional patches.

1 - 55 Copyright 2007, Oracle. All rights reserved.

Hot Patching Considerations (continued)


A vast majority of diagnostic patches are available as hot patches. For bug fixes, it really depends on
their nature. Not every bug fix or diagnostic patch is available as a hot patch. But the long-term goal
of the hot-patching facility is to provide hot-patching capabilities for Critical Patch Updates.

Oracle Database 11g: New Features for Administrators 1 - 55


Practice 1-4: Overview

In this practice, you create a database.

1 - 56 Copyright 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 1 - 56


Summary

In this lesson, you should have learned how to:


Install Oracle Database 11g
Upgrade your database to Oracle Database 11g
Use hot patching

1 - 57 Copyright 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 1 - 57


Storage Enhancements

Copyright 2007, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to:


Set up ASM fast mirror resync
Use ASM preferred mirror read
Understand scalability and performance enhancements
Set up ASM disk group attributes
Use the SYSASM role
Use various new manageability options for CHECK,
MOUNT, and DROP commands
Use the ASMCMD md_backup, md_restore, and
repair extensions

2-2 Copyright 2007, Oracle. All rights reserved.

Note: In this lesson, the term ASM data extent is shortened to extent.

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


Without ASM Fast Mirror Resync
1 ASM redundancy used 2 Disk access failure

Secondary
Primary

extent
extent

Oracle Database 10g and 11g

4 Disk added back: 3 Disk automatically dropped:


Extents rebalanced All dropped extents re-created

2-3 Copyright 2007, Oracle. All rights reserved.

Without ASM Fast Mirror Resync


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

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


ASM Fast Mirror Resync: Overview
1 ASM redundancy used 2 Disk access failure

Secondary
Primary

extent
extent

Oracle Database 11g

Disk again accessible;


4
3 Failure time < DISK_REPAIR_TIME
need only to resync modified extents

2-4 Copyright 2007, Oracle. All rights reserved.

ASM Fast Mirror Resync: Overview


ASM fast mirror resync significantly reduces the time required to resynchronize a transient failure of
a disk. When a disk goes offline following a transient failure, ASM tracks the extents that are
modified during the outage. When the transient failure is repaired, ASM can quickly resynchronize
only the ASM disk extents that have been affected during the outage.
This feature assumes that the content of the affected ASM disks has not been damaged or modified.
When an ASM disk path fails, the ASM disk is taken offline but not dropped if you have set the
DISK_REPAIR_TIME attribute for the corresponding disk group. The setting for this attribute
determines the duration of disk outage that ASM will tolerate while still being able to resynchronize
after you complete the repair.
Note: The tracking mechanism uses one bit for each modified extent. This ensures that the tracking
mechanism is very efficient.

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


Using EM to Perform Fast Mirror Resync

2-5 Copyright 2007, Oracle. All rights reserved.

Using EM to Perform Fast Mirror Resync


When you offline an ASM disk in Oracle Enterprise Manager (EM), you are asked to confirm the
operation. On the Confirmation page, you can override the default disk repair time. Similarly, you
can view by failure group and choose a particular failure group to offline.

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


Using EM to Perform Fast Mirror Resync

2-6 Copyright 2007, Oracle. All rights reserved.

Using EM to Perform Fast Mirror Resync (continued)


You can also online disks by using Enterprise Manager.

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


Setting Up ASM Fast Mirror Resync

ALTER DISKGROUP dgroupA SET ATTRIBUTE 'DISK_REPAIR_TIME'='3H';

ALTER DISKGROUP dgroupA


OFFLINE DISKS IN FAILGROUP contrl2 DROP AFTER 5H;

ALTER DISKGROUP dgroupA


ONLINE DISKS IN FAILGROUP contrler2 POWER 2 WAIT;

ALTER DISKGROUP dgroupA DROP DISKS IN FAILGROUP contrl2 FORCE;

2-7 Copyright 2007, Oracle. All rights reserved.

Setting Up ASM Fast Mirror Resync


You set up this feature on a perdisk group basis. You can do so after disk-group creation using the
ALTER DISKGROUP command. Use a command similar to the following to enable ASM fast mirror
resync:
ALTER DISKGROUP SET ATTRIBUTE 'DISK_REPAIR_TIME'='2D4H30M'
After you repair the disk, run the SQL statement ALTER DISKGROUP ONLINE DISK. This
statement brings a repaired disk group back online to enable writes so that no new writes are missed.
This statement also starts a procedure to copy all extents that are marked as stale on their redundant
copies. You cannot apply the ONLINE statement to already-dropped disks.
You can view the current attribute values by querying the V$ASM_ATTRIBUTE view.
You can determine the time left before ASM drops an offlined disk by querying the
REPAIR_TIMER column of either V$ASM_DISK or V$ASM_DISK_IOSTAT. In addition, a row
corresponding to a disk resync operation appears in V$ASM_OPERATION with the OPERATION
column set to SYNC.

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


Setting Up ASM Fast Mirror Resync (continued)
You can also use the ALTER DISKGROUP OFFLINE DISK SQL statement to manually bring the
ASM disks offline for preventive maintenance. With this command, you can specify a timer to
override the timer that is defined at the disk-group level. After you complete maintenance, use the
ALTER DISKGROUP ONLINE DISK statement to bring the disk online.
If you cannot repair a failure group that is in the offline state, you can use the ALTER DISKGROUP
DROP DISKS IN FAILGROUP command with the FORCE option. This ensures that data originally
stored on these disks is reconstructed from redundant copies of the data and stored on other disks in
the same disk group.
Note: The time elapses only when the disk group is mounted. Furthermore, changing the value of
DISK_REPAIR_TIME does not affect disks previously offlined. The default setting of 3.6 hours for
DISK_REPAIR_TIME should be adequate for most environments.

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


ASM Preferred Mirror Read: Overview
Site A Site B

P S

Site A Site B

P P: Primary AU S
S: Secondary AU

2-9 Copyright 2007, Oracle. All rights reserved.

ASM Preferred Mirror Read: Overview


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

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


ASM Preferred Mirror Read: Setup

Setup

On first instance
ASM_PREFERRED_READ_FAILURE_GROUPS=DATA.SITEA

On second instance
ASM_PREFERRED_READ_FAILURE_GROUPS=DATA.SITEB

Monitor

SELECT preferred_read FROM v$asm_disk;

SELECT * FROM v$asm_disk_iostat;

2 - 10 Copyright 2007, Oracle. All rights reserved.

ASM Preferred Mirror Read: Setup


To configure this feature, set the new ASM_PREFERRED_READ_FAILURE_GROUPS initialization
parameter. This parameter is a multivalued parameter and should contain a string with a list of failure
group names separated by commas. Each failure group name specified should be prefixed with its
disk group name and a . character. This parameter is dynamic and can be modified using the
ALTER SYSTEM command at any time. An example is shown in the slide. However, this
initialization parameter is valid only for ASM instances. With the extended cluster, the failure groups
specified in this parameter should contain only those disks that are local to the corresponding
instance.
The new column PREFERRED_READ has been added to the V$ASM_DISK view. Its format is a
single character. If the disk group to which the disk belongs pertains to a preferred read failure group,
the value of this column is Y.
To identify specific performance issues with the ASM preferred read failure groups, use the
V$ASM_DISK_IOSTAT view. This view displays the disk I/O statistics for each ASM client. If this
view is queried from a database instance, only the rows for this instance are shown.

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


Enterprise Manager ASM Configuration Page

2 - 11 Copyright 2007, Oracle. All rights reserved.

Enterprise Manager ASM Configuration Page


You can specify a set of disks as preferred disks for each ASM instance by using Enterprise
Manager. The preferred read attributes are instance-specific. In Oracle Database 11g, the Preferred
Read Failure Groups field (asm_preferred_read_failure_group) is added to the
configuration page.
This parameter only takes effect before the disk group is mounted or when the disk group is created.
It applies only to newly opened files or to a newly loaded extend map for a file.

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


ASM Preferred Mirror Read: Best Practice

Two sites: normal redundancy Two sites: high redundancy

P S P S S S S P

Only two failure groups: one for each instance Max four failure groups: two for each instance

Three sites: high redundancy

P S S

Only three failure groups: one for each instance

2 - 12 Copyright 2007, Oracle. All rights reserved.

ASM Preferred Mirror Read: Best Practice


In practice, there are only a limited number of good disk group configurations in an extended cluster.
A good configuration takes into account both performance and availability of a disk group in an
extended cluster. Here are some possible examples:
For a two-site extended cluster, a normal redundancy disk group should have only two failure
groups; all disks local to one site should belong to the same failure group. Also, no more than one
failure group should be specified as a preferred read failure group by each instance. If there are more
than two failure groups, ASM may not mirror a virtual extent across both sites. Furthermore, if the
site with more than two failure groups were to go down, it would take the disk group down as well. If
the disk group to be created is a high-redundancy disk group, at most two failure groups should be
created on each site with its local disks, with both local failure groups specified as preferred read
failure groups for the local instance.
For a three-site extended cluster, a high redundancy disk group with three failure groups should be
used. In this way, ASM can guarantee that each virtual extent has a mirror copy local to each site and
that the disk group is protected against a catastrophic disaster on any of the three sites.

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


ASM Scalability and Performance Enhancements

Extent size grows automatically according to file size.


ASM supports variable extent sizes to:
Raise the maximum possible file size
Reduce memory utilization in the shared pool
There are no administration needs other than manual
rebalance in case of important fragmentation.

2 - 13 Copyright 2007, Oracle. All rights reserved.

ASM Scalability and Performance Enhancements


ASM Variable Size Extents is an automated feature that enables ASM to support larger file sizes
while improving memory usage efficiency.
In Oracle Database 11g, ASM supports variable sizes for extents of 1, 8, and 64 allocation units
(AU). ASM uses a predetermined number of extents of each size. As soon as a file crosses a certain
threshold, the next extent size is used.
With this feature, fewer extent pointers are needed to describe the file and less memory is required to
manage the extent maps in the shared pool (which would have been prohibitive in large file
configurations). Extent size can vary both across files and within files.
Variable Size Extents also enables you to deploy Oracle databases using ASM that are several
hundred TB (or even several PB) in size.
Note: The management of Variable Size Extents is completely automated and does not require
manual administration.

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


ASM Scalability and Performance Enhancements (continued)
However, external fragmentation may occur when a large number of noncontiguous small data
extents have been allocated and freed, and no additional contiguous large extents are available. A
defragmentation operation is integrated as part of any rebalance operation. As a result, as a DBA,
you always have the ability to defragment your disk group by executing a rebalance operation.
Nevertheless, this should happen only very rarely because ASM also automatically performs
defragmentation during extents allocation if the desired size is unavailable. This can potentially make
some allocation operations longer.
Note: This feature also enables much faster file opens because of the significant reduction in the
amount of memory that is required to store file extents.

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


ASM Scalability in Oracle Database 11g

ASM imposes the following limits:


63 disk groups
10,000 ASM disks
4 petabytes per ASM disk
40 exabytes of storage
1 million files per disk group
Maximum file size:
External redundancy: 140 PB
Normal redundancy: 42 PB
High redundancy: 15 PB

2 - 15 Copyright 2007, Oracle. All rights reserved.

ASM Scalability in Oracle Database 11g


ASM imposes the following limits:
63 disk groups in a storage system
10,000 ASM disks in a storage system
4 petabytes maximum storage for each ASM disk
40 exabytes maximum storage for each storage system
1 million files for each disk group
Maximum file size depends on the redundancy type of the disk groups used: 140 PB for external
redundancy (value currently greater than possible database file size), 42 PB for normal
redundancy, and 15 PB for high redundancy.
Note: In Oracle Database 10g, the maximum ASM file size for external redundancy is 35 TB.

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


SYSASM Role

Using the SYSASM role to manage ASM instances


avoids overlap between DBAs and storage
administrators.
SQL> CONNECT / AS SYSASM

SQL> CREATE USER username IDENTIFIED by passwd;

SQL> GRANT SYSASM TO username;

SQL> CONNECT username/passwd AS SYSASM;

SQL> DROP USER username;

SYSDBA will be deprecated:


Oracle Database 11g, Release 1 behaves as in 10g.
In future releases, SYSDBA privileges will be restricted
in ASM instances.
2 - 16 Copyright 2007, Oracle. All rights reserved.

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

2 - 17 Copyright 2007, Oracle. All rights reserved.

Using EM to Manage ASM Users


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

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


ASM Disk Group Compatibility

The compatibility of each disk group is separately


controllable:
ASM compatibility controls ASM metadata on-disk
structure.
RDBMS compatibility controls the minimum consumer
client level.
This is useful with heterogeneous environments.
Setting disk group compatibility is irreversible.

DB ASM disk ASM


instance group instance

COMPATIBLE >= COMPATIBLE.RDBMS


<=
COMPATIBLE.ASM <= COMPATIBLE

2 - 18 Copyright 2007, Oracle. All rights reserved.

ASM Disk Group Compatibility


There are two kinds of compatibility applicable to ASM disk groups:
ASM compatibility: Dealing with the persistent data structures that describe a disk group
RDBMS compatibility: Dealing with the capabilities of the clients (consumers of disk groups)
The compatibility of each disk group is independently controllable. This is required to enable
heterogeneous environments with disk groups from both Oracle Database 10g and Oracle Database
11g. These two compatibility settings are attributes of each ASM disk group:
RDBMS compatibility refers to the minimum compatible version of the RDBMS instance that
would allow the instance to mount the disk group. This compatibility determines the format of
messages that are exchanged between the ASM and database (RDBMS) instances. An ASM
instance is capable of supporting different RDBMS clients running at different compatibility
settings. The database-compatible version setting of each instance must be greater than or equal
to the RDBMS compatibility of all disk groups used by that database. Database instances are
typically run from a different Oracle home than the ASM instance. This implies that the
database instance may be running a different software version than the ASM instance. When a
database instance first connects to an ASM instance, it negotiates the highest version that they
both can support. The compatibility parameter setting of the database, the software version of
the database, and the RDBMS compatibility setting of a disk group determine whether a
database instance can mount a given disk group.

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


ASM Disk Group Compatibility (continued)
ASM compatibility refers to the persistent compatibility setting controlling the format of data
structures for ASM metadata on disk. The ASM compatibility level of a disk group must always
be greater than or equal to the RDBMS compatibility level of the same disk group. ASM
compatibility is concerned only with the format of the ASM metadata. The format of the file
contents is determined by the database instance. For example, the ASM compatibility of a disk
group can be set to 11.0 while its RDBMS compatibility could be 10.1. This implies that the
disk group can be managed only by ASM software whose software version is 11.0 or higher,
while any database client whose software version is higher than or equal to 10.1 can use that
disk group.
The compatibility of a disk group needs to be advanced only when there is a change to either
persistent disk structures or protocol messaging. However, advancing disk group compatibility is an
irreversible operation. You can set the disk group compatibility by using either the CREATE
DISKGROUP command or the ALTER DISKGROUP command.
Note: In addition to disk group compatibilities, the compatible parameter (database compatible
version) determines the features that are enabled. It applies to the database or ASM instance
depending on the instance_type parameter. For example, setting it to 10.1 would preclude use of any
new features that are introduced in Oracle Database 11g (disk online/offline, variable extents, and so
on).

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


ASM Disk Group Attributes

Name Property Values Description


au_size C 1|2|4|8|16|32|64MB Size of allocation units in the disk group

compatible.rdbms AC Valid database version Format of messages exchanged between DB


and ASM
compatible.asm AC Valid ASM instance Format of ASM metadata structures on disk
version
disk_repair_time AC 0 M to 232 D Length of time before removing a disk once
OFFLINE
template.tname. A UNPROTECT|MIRROR|HIGH Redundancy of specified template
redundancy
template.tname. A COARSE|FINE Striping attribute of specified template
stripe
C: CREATE
A: ALTER

CREATE DISKGROUP DATA NORMAL REDUNDANCY


DISK '/dev/raw/raw1','/dev/raw/raw2'
ATTRIBUTE 'compatible.asm'='11.1';

2 - 20 Copyright 2007, Oracle. All rights reserved.

ASM Disk Group Attributes


When you create or alter an ASM disk group, you can change its attributes by using the new
ATTRIBUTE clause of the CREATE DISKGROUP or ALTER DISKGROUP commands. These
attributes are briefly summarized in the table in the slide:
ASM enables the use of different AU sizes that you specify when you create a disk group. The
AU size can be 1 MB, 2 MB, 4 MB, 8 MB, 16 MB, 32 MB, or 64 MB.
RDBMS compatibility: See the slide titled ASM Disk Group Compatibility for more
information.
ASM compatibility: See the slide titled ASM Disk Group Compatibility for more information.
You can specify the DISK_REPAIR_TIME in units of minutes (M), hours (H), or days (D).
If you omit the unit, the default is H. If you omit this attribute, then the default is 3.6H. You can
override this attribute with an ALTER DISKGROUP statement.
You can specify the redundancy attribute of the specified template.
You can specify the striping attribute of the specified template.
Note: For each defined disk group, you can look at all the defined attributes by using the
V$ASM_ATTRIBUTE fixed view.

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


Using EM to Edit Disk Group Attributes

2 - 21 Copyright 2007, Oracle. All rights reserved.

Using EM to Edit Disk Group Attributes


EM provides a simple way to store and retrieve environment settings related to disk groups.
You can now set the compatible attributes from both the Create Disk Group page and the Edit
Advanced Attributes for Disk Group page. The disk_repair_time attribute is added to only the
Edit Advanced Attributes for Disk Group page.
Note: For 11g ASM instances, the default ASM and Database compatibility values are 11.1.

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


Enhanced Disk Group Checks

Disk group check syntax is simplified.


FILE and DISK options do the same as ALL.
Additional checks performed:
Alias
Directories

ALTER DISKGROUP DATA CHECK;

2 - 22 Copyright 2007, Oracle. All rights reserved.

Enhanced Disk Group Checks


The CHECK disk group command is simplified to check all the metadata directories by default. The
CHECK command lets you verify the internal consistency of the ASM disk group metadata.
ASM displays summary errors and writes the details of the detected errors in the alert log.
In earlier releases, you could specify this clause for ALL, DISK, DISKS IN FAILGROUP, and
FILE. Those clauses have been deprecated because they are no longer needed. In the current release,
the CHECK keyword performs the following operations:
Checks the consistency of the disk (equivalent to CHECK DISK and CHECK DISK IN
FAILGROUP in previous releases)
Cross-checks all the file extent maps and allocation tables for consistency (equivalent to CHECK
FILE in previous releases)
Checks that the alias metadata directory and the file directory are linked correctly
Checks that the alias directory tree is linked correctly
Checks that ASM metadata directories do not have unreachable allocated blocks
The REPAIR | NOREPAIR clause enables you to tell ASM whether or not to attempt to repair the
errors found during the consistency check. The default is REPAIR. The NOREPAIR setting is useful
when you want to be alerted to any inconsistencies but do not want ASM to take any automatic
action to resolve them.
Note: Introducing extra checks as part of check disk group slows down the entire check disk group
operation.
Oracle Database 11g: New Features for Administrators 2 - 22
Restricted Mount Disk Group for Fast Rebalance

A disk group can be mounted on a single instance only.


No database client or other ASM instance can obtain
access.
Rebalance can proceed without locking overhead.

1 ALTER DISKGROUP data DISMOUNT;

2 ALTER DISKGROUP data MOUNT RESTRICT;

3 Maintenance task: Add/Remove disks

4 ALTER DISKGROUP data DISMOUNT;

5 ALTER DISKGROUP data MOUNT;

2 - 23 Copyright 2007, Oracle. All rights reserved.

Restricted Mount Disk Group for Fast Rebalance


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

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


Mount Force Disk Group

By default, MOUNT is NOFORCE:


All disks must be available.
MOUNT with FORCE:
Offlines unavailable disks if quorum exists
Fails if all disks are available
ALTER DISKGROUP data MOUNT [FORCE|NOFORCE];

2 - 24 Copyright 2007, Oracle. All rights reserved.

Mount Force Disk Group


This feature alters the behavior of ASM when mounting an incomplete disk group.
With Oracle Database 10g, as long as there are enough failure groups to mount a disk group, the
mount operation succeeds, even when there are missing or damaged failure groups. This behavior has
the potential to automatically drop ASM disks, requiring their addition again later after repair, and
thus incurring a long rebalance operation.
With Oracle Database 11g, such an operation fails unless you specify the new FORCE option when
mounting the damaged disk group. This allows you to correct configuration errors (such as
ASM_DISKSTRING set incorrectly) or connectivity issues before trying the mount again.
However, disk groups mounted with the FORCE option could potentially have one or more disks
offline if they were not available at the time of the mount. You must take corrective action before
DISK_REPAIR_TIME expires to restore those devices. Failing to online those devices results in the
disks being expelled from the disk group and costly rebalancing being required to restore redundancy
for all the files in the disk group. Also, if one or more devices are offlined as a result of MOUNT
FORCE, some or all files will not be properly protected until the redundancy is restored in the disk
group via rebalance.
Therefore, MOUNT with FORCE is useful when you know that some of the disks belonging to a disk
group are unavailable. The disk group mount succeeds if ASM finds enough disks to form a quorum.

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


Mount Force Disk Group (continued)
MOUNT with NOFORCE is the default option of MOUNT when none is specified. In NOFORCE mode,
all disks that belong to a disk group must be accessible for the mount to succeed.
Note: Specifying the FORCE option when it is not necessary also results in an error. There is also one
special case in a cluster: If an ASM instance is not the first to mount the disk group, MOUNT FORCE
fails with an error if disks are determined to be inaccessible locally but accessible by another
instance.

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


Forcing Disk Group Drop

Allows users to drop disk groups that cannot be


mounted
Fails if disk group is mounted anywhere
DROP DISKGROUP data FORCE INCLUDING CONTENTS;

2 - 26 Copyright 2007, Oracle. All rights reserved.

Forcing Disk Group Drop


Drop disk group force marks the headers of disks belonging to a disk group that cannot be mounted
by the ASM instance as FORMER. However, the ASM instance first determines whether the disk
group is being used by any other ASM instance using the same storage subsystem. If it is being used,
and if the disk group is in the same cluster or on the same node, the statement fails.
If the disk group is in a different cluster, the system checks further to determine whether the disk
group is mounted by an instance in the other cluster. If the disk group is mounted elsewhere, the
statement fails. However, this latter check is not as definitive as the checks for disk groups in the
same cluster. You should therefore use this clause with caution.
Note: When executing the DROP DISKGROUP command with the FORCE option, you must also
specify the INCLUDING CONTENTS clause.

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


ASMCMD Extensions

User-created directories
Templates
Disk group compatibility md_backup
Disk group name full
Disk names and failure groups

repair $ asmcmd help md_restore nodg

newdg
lsdsk

2 - 27 Copyright 2007, Oracle. All rights reserved.

ASMCMD Extensions
ASMCMD is extended to include ASM metadata backup and to restore functionality. This
provides the ability to re-create a preexisting ASM disk group with the exact template and alias
directory structure. Currently, if an ASM disk group is lost, it is possible to restore the lost files
by using RMANbut you must manually re-create the ASM disk group and any required user
directories or templates.
ASM metadata backup and restore (AMBR) works in two modes:
- In backup mode, AMBR parses ASM fixed tables and views to gather information about
existing disks and failure group configurations, templates, and alias directory structures.
It then dumps this metadata information to a text file.
- In restore mode, AMBR reads the previously generated file to reconstruct the disk group
and its metadata. You have the ability to control AMBR behavior in restore mode to do a
full, nodg, or newdg restore. The difference among the three submodes is in whether
you want to include the disk group creation and change its characteristics.
The lsdsk command lists ASM disk information. This command can run in two modes:
- In connected mode, ASMCMD uses the V$ and GV$ views to retrieve disk information.
- In nonconnected mode, ASMCMD scans disk headers to retrieve disk information, using an
ASM disk string to restrict the discovery set. The connected mode is always attempted first.

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


ASMCMD Extensions (continued)
Bad block repair is a new feature that runs automatically on normal or high redundancy disk
groups. When a normal read from an ASM disk group fails with an I/O error, ASM attempts to
repair that block by reading from the mirror copy and writing to it, and by relocating it if the
copy failed to produce a good read. This whole process happens automatically only on blocks
that are read. It is possible that some blocks and extents on an ASM disk group are seldom read.
One important example is the secondary extents. The ASMCMD repair command is designed
to trigger a read on these extents, so the resulting failure in I/O can start the automatic block
repair process. You can use the ASMCMD repair interface if the storage array returns an error
on a physical block; ASMCMD repair can then initiate a read on that block to trigger the
repair.
Note: For more information about the syntax for each of these commands, see the Oracle Database
Storage Administrators Guide.

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


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

2 Unintentional disk group drop

ASMCMD> md_restore -b jfv_backup_file -t full -g data


Disk group to be restored: DATA#
ASMCMDAMBR-09358, Option -t newdg specified without any override
options.
3 Current Diskgroup being restored: DATA
Diskgroup DATA created!
User Alias directory +DATA/jfv
created!
ASMCMD>

4 Restore disk group files by using RMAN

2 - 29 Copyright 2007, Oracle. All rights reserved.

ASMCMD Extensions: Example


This example describes how to back up ASM metadata by using the md_backup command, and
how to restore the data by using the md_restore command.
The first statement specifies the b option and the g option of the command. This defines the name
of the generated file containing the backup information as well as the disk group that needs to be
backed up (jfv_backup_file and data, respectively, in the slide).
In step 2, it is assumed that there is a problem in the DATA disk group. As a result, it gets dropped.
Before you can restore the database files that the disk group contained, you have to restore the disk
group itself.
In step 3, you initiate the disk group re-creation as well as restoration of its metadata by using the
md_restore command. Here you specify the name of the backup file generated in step 1 as well as
the name of the disk group that you want to restore, plus the type of restore that you want. In this
example, a full restore of the disk group is done because it no longer exists.
After the disk group is re-created, you can restore its database files by using (for example) RMAN.

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


Summary

In this lesson, you should have learned how to:


Set up ASM fast mirror resync
Use ASM preferred mirror read
Set up ASM disk group attributes
Use the SYSASM role
Use various new manageability options for CHECK,
MOUNT, and DROP commands
Use the ASMCMD md_backup, md_restore, and
repair extensions

2 - 30 Copyright 2007, Oracle. All rights reserved.

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


Practice 2: Overview

This practice covers the following topics:


Using ASM fast mirror resync
Using ASMCMD extensions

2 - 31 Copyright 2007, Oracle. All rights reserved.

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


SQL Performance Analyzer

Copyright 2007, Oracle. All rights reserved.


Change Management in Oracle Database 11g

Lesson 3: SQL Performance Analyzer


Lesson 4: SQL Plan Management
Lesson 5: Database Replay

3-2 Copyright 2007, Oracle. All rights reserved.

Change Management in Oracle Database 11g


This lesson begins with a brief introduction to the Change Management features and benefits in
Oracle Database 11g, which are covered in three lessons.
Lesson 3 (SQL Performance Analyzer) begins on slide 9.

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


Challenges Faced by DBAs
When Performing Changes

Maintaining service-level agreements through changes


to hardware or software configurations
Offering production-level workload environment for
testing purposes
Effectively forecasting and analyzing impact on SQL
performance

3-3 Copyright 2007, Oracle. All rights reserved.

Challenges Faced by DBAs When Performing Changes


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

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


3-4 Copyright 2007, Oracle. All rights reserved.

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


3-5 Copyright 2007, Oracle. All rights reserved.

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


3-6 Copyright 2007, Oracle. All rights reserved.

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


Setting Up a Test Environment
by Using the Snapshot Standby Database

Redo Physical standby


stream database

Open database as Back out testing


snapshot standby. changes.

Redo Snapshot standby Perform


stream database testing

3-7 Copyright 2007, Oracle. All rights reserved.

Setting Up a Test Environment by Using the Snapshot Standby Database


In Oracle Database 11g, a physical standby database can be opened temporarily (that is, activated)
for read or write activities such as reporting and testing.
A physical standby database in the snapshot standby state still receives redo data from the primary
database, thereby providing data protection for the primary database while still in the reporting or
testing database role.
You convert a physical standby database to a snapshot standby database, and you open the snapshot
standby database for writes by applications for testing. When you have completed testing, you
discard the testing writes and catch up with the primary database by applying the redo logs.
Creating a snapshot standby database was possible with the previous releases. However, Oracle
Database 11g simplifies greatly the way you set up a snapshot standby database.
For more information about snapshot standby databases, refer to the Oracle Data Guard Concepts
and Administration Guide.
Note: Another important feature is the real-time query capability of physical standby databases in
Oracle Database 11g. This feature makes it possible to query a physical standby database while Redo
Apply is active.

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


Benefits of Snapshot Standby

A snapshot standby database is activated from a physical


standby database.
Redo stream is continually accepted.
Provides for disaster recovery
Users can continue to query or update.
Snapshot standby is open read/write.
Benefits reporting applications
Reduces storage requirements

3-8 Copyright 2007, Oracle. All rights reserved.

Benefits of Snapshot Standby


A snapshot standby database is a database that is activated from a physical standby database to be
used for reporting and testing. The snapshot standby database receives redo from the primary
database and continues to provide data protection for the primary database. The snapshot standby
database:
Is like the primary database in that the users can perform queries or updates
Is like a physical standby database in that it continues receiving redo data from the primary
database
A snapshot standby database provides the combined benefit of disaster recovery and of reporting and
testing using a physical standby database. Although similar to storage snapshots, snapshot standby
databases provide a single copy of storage while maintaining disaster recovery.

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


SQL Performance Analyzer

3-9 Copyright 2007, Oracle. All rights reserved.

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


Objectives

After completing this lesson, you should be able to:


Identify the benefits of using SQL Performance
Analyzer
Describe the SQL Performance Analyzer workflow
phases
Use SQL Performance Analyzer to ascertain
performance gains following a database change

3 - 10 Copyright 2007, Oracle. All rights reserved.

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


SQL Performance Analyzer: Overview

New 11g feature


Targeted users: DBAs, QAs, application developers
Helps predict the impact of system changes on SQL
workload response time
Builds different versions of SQL workload performance
(that is, SQL execution plans and execution statistics)
Executes SQL serially (concurrency not honored)
Analyzes performance differences
Offers fine-grained performance analysis on individual
SQL
Integrated with SQL Tuning Advisor to tune
regressions

3 - 11 Copyright 2007, Oracle. All rights reserved.

SQL Performance Analyzer: Overview


Oracle Database 11g introduces SQL Performance Analyzer, which gives you an exact and accurate
assessment of the impact of change on the SQL statements that make up the workload. SQL
Performance Analyzer helps you forecast the impact of a potential change on the performance of a
SQL query workload. This capability provides DBAs with detailed information about the
performance of SQL statements, such as before-and-after execution statistics, and statements with
performance improvement or degradation. This enables you (for example) to make changes in a test
environment to determine whether the workload performance will be improved through a database
upgrade.

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


SQL Performance Analyzer: Use Cases

SQL Performance Analyzer is beneficial in the following


use cases:
Database upgrades
Implementation of tuning recommendations
Schema changes
Statistics gathering
Database parameter changes
OS and hardware changes

3 - 12 Copyright 2007, Oracle. All rights reserved.

SQL Performance Analyzer: Use Cases


SQL Performance Analyzer can be used to predict and prevent potential performance problems for
any database environment change that affects the structure of the SQL execution plans. The changes
can include (but are not limited to) any of the following:
Database upgrades
Implementation of tuning recommendations
Schema changes
Statistics gathering
Database parameter changes
OS and hardware changes
DBAs can use SQL Performance Analyzer to foresee SQL performance changes that result from the
preceding changes for even the most complex environments. As applications evolve through the
development lifecycle, database application developers can test (for example) changes to schemas,
database objects, and rewritten applications to mitigate any potential performance impact.
SQL Performance Analyzer also enables the comparison of SQL performance statistics.

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


Usage Model: Capture SQL Workload

SQL Tuning Set (STS) is used to


store SQL workload. Includes:
SQL Text
Bind variables
Cursor cache Execution plans
Incremental capture
Execution statistics
Incremental capture is used to
Database Instance
populate STS from cursor cache
over a period of time.
STSs filtering and ranking
capabilities filter out undesirable
SQL.

Production
database

3 - 13 Copyright 2007, Oracle. All rights reserved.

Usage Model: Capture SQL Workload


The first step to using SQL Performance Analyzer is to capture the SQL statements that represent
your workload. This is done using the SQL Tuning Set technology.

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


Usage Model: Transport to a Test System

Cursor cache

Database instance Database instance

Production Test
database database

Copy SQL Tuning Set to staging table (pack).


Transport staging table to test system (data pump, DB link, etc).
Copy SQL Tuning Set from staging table (unpack).

3 - 14 Copyright 2007, Oracle. All rights reserved.

Usage Model: Transport to a Test System


The second step is to transport these SQL statements to a similar system that is being tested. Here,
STS can be exported from production and then imported into a test system.

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


Usage Model: Build Before Change Performance

Before change, SQL performance Test/execute


version is the SQL workload
performance baseline.
SQL performance = execution plans
+ execution statistics
Test/execute SQL in STS: Before
changes
Produce execution plans and Database instance
statistics.
Execute SQL serially
(no concurrency).
Every SQL is executed only once.
Skip DDL/DML effects.
Explain plan SQL in STS to
generate SQL plans only. Test
database

3 - 15 Copyright 2007, Oracle. All rights reserved.

Usage Model: Build Before Change Performance


The third step is to capture a baseline of the test system performance consisting of the execution plan
and execution statistics.

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


Usage Model: Build After Change Performance

Manually implement the planned


change:
Database upgrade
Implementation of tuning
recommendations
Schema changes
After
Statistics gathering changes Database instance
Database parameter changes After changes
implemented
OS and hardware changes
Reexecute SQL after change:
Test/execute SQL in STS to
generate SQL execution plans and
statistics.
Explain plan SQL in STS to Test
generate SQL plans. database

3 - 16 Copyright 2007, Oracle. All rights reserved.

Usage Model: Build After Change Performance


The fourth step is to make the changes to the test system and then rerun the SQL statements to assess
the impact of the changes on the SQL performance.

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


Usage Model: Compare and Analyze Performance
Rely on user-specified metric to
SQL Tuning Advisor
compare SQL performance:
elapsed_time, buffer_gets,
disk_reads, ...
Calculate impact of change on
individual SQLs and SQL workload: Improvement Regression
Overall impact on workload
Compare
Net SQL impact on workload analysis

Use SQL execution frequency to Database instance

define a weight of importance.


Detect improvements, regressions,
and unchanged performance.
Detect changes in execution plans.
Recommend running SQL Tuning
Advisor to tune regressed SQLs. Test
Analysis results can be used to seed database
SQL Plan Management baselines.

3 - 17 Copyright 2007, Oracle. All rights reserved.

Usage Model: Compare and Analyze Performance


Enterprise Manager provides the tools to make a full comparison of performance data, including
execution statistics such as elapsed time, CPU time, and buffer gets. If the SQL performance has
regressed in some of the cases, the DBA must then run SQL Tuning Advisor to tune the SQL
statementseither immediately or at a scheduled time. As with any tuning strategy, it is
recommended that only one change be implemented at a time and retested before making further
changes.

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


SQL Performance Analyzer: Summary

1. Capture SQL workload on production.


2. Transport the SQL workload to a test system.
3. Build before-change performance data.
4. Make changes.
5. Build after-change performance data.
6. Compare results from steps 3 and 5.
7. Tune regressed SQL.

3 - 18 Copyright 2007, Oracle. All rights reserved.

SQL Performance Analyzer: Summary


1. Gather SQL: In this phase, you collect the set of SQL statements that represent your SQL
workload on the production system. You can use SQL Tuning Sets or Automatic Workload
Repository (AWR) to capture the information to transport. Because AWR essentially captures
high-load SQLs, you should consider modifying the default AWR snapshot settings and
captured Top SQL to ensure that AWR captures the maximum number of SQL statements. This
ensures more complete SQL workload capture.
2. Transport: Here you transport the resultant workload to the test system. The STS is exported
from the production system and the STS is imported into the test system.
3. Compute before-version performance: Before any changes take place, you execute the SQL
statements, collecting baseline information that is needed to assess the impact that a future
change might have on the performance of the workload. The information collected in this stage
represents a snapshot of the current state of the system workload. The performance data
includes:
- Execution plans (for example, generated by explain plan)
- Execution statistics (for example, includes elapsed time, buffer gets, disk reads, and rows
processed)
4. Make a change: After you have the before-version data, you can implement your planned change
and start viewing the impact on performance.

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


SQL Performance Analyzer: Summary (continued)
5. Compute after-version performance: This step takes place after the change is made in the
database environment. Each statement of the SQL workload runs under a mock execution
(collecting statistics only), collecting the same information as captured in step 3.
6. Compare and analyze SQL Performance: After you have both versions of the SQL workload
performance data, you can carry out the performance analysis by comparing the after-version
data with the before-version data. The comparison is based on the execution statistics, such as
elapsed time, CPU time, and buffer gets.
7. Tune regressed SQL: At this stage, you have identified exactly which SQL statements may
cause performance problems when the database change is made. Here, you can use any of the
database tools to tune the system. For example, you can use SQL Tuning Advisor or Access
Advisor against the identified statements and then implement those recommendations.
Alternatively, you can seed SQL Plan Management (SPM) with plans captured in step 3 to
guarantee that the plans remain the same. After implementing any tuning action, you should
repeat the process to create a new after-version and analyze the performance differences to
ensure that the new performance is acceptable.

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


Capturing the SQL Workload

1. Create SQL Tuning Set (STS) on original system.


2. Create a staging table and upload STS in staging table.
3. Export staging table to test system.
4. Unpack staging table to STS on test system.

3 - 20 Copyright 2007, Oracle. All rights reserved.

Capturing the SQL Workload


Capturing SQL workload is done using SQL Tuning Sets (STS). This concept is not new in Oracle
Database 11g, and it follows exactly the same workflow as with previous releases of the database.
This workflow is briefly described in the slide. You can use either Enterprise Manager wizards or the
DBMS_SQLTUNE PL/SQL package.
With Oracle Database 11g, you access the SQL Tuning Sets page from the Performance tab in
Database Control.
The workload that you capture should reflect a representative period of time (in captured SQL
statements) that you wish to test under some changed condition. The following information is
captured in this process:
The SQL text
The execution context (including bind values, parsing schema, and compilation environment),
which contains a set of initialization parameters under which the statement is executed
The execution frequency, which tells how many times the SQL statement has been executed
during the time interval of the workload
Normally the capture SQL happens on the production system to capture the workload running on it.
The performance data is computed later on the test system by the compute SQL performance
processes. SQL Performance Analyzer tracks the SQL performance of the same STS before and after
a change is made to the database.

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


Creating a SQL Performance Analyzer Task

3 - 21 Copyright 2007, Oracle. All rights reserved.

Creating a SQL Performance Analyzer Task


EM helps you manage each component in the SQL Performance Analyzer process and reports the
analysis result. The workflow and user interface apply to both EM Database Control and EM Grid
Control.
You access SQL Performance Analyzer from the Software and Support tab of Database Control.
Alternatively, select Database Instance > Advisor Central > Advisors > SQL Performance Analyzer.
SQL Performance Analyzer offers three workflows for you to test different scenarios:
Optimizer Upgrade Simulation: Test the effects of specified optimizer version changes on
SQL Tuning Set performance. A SQL Performance Analyzer task is created and an initial trial
run is performed with the optimizer_features_enable parameter set to an initial value.
A second trial run is performed with the optimizer_features_enable parameter set to
the targeted version. A replay trial comparison report is then run for the two trials.
Parameter Change: Test and compare an initialization parameter change on SQL Tuning Set
performance. A SQL Performance Analyzer task is created and an initial trial run is performed
with the parameter set to the base value. A second trial run is performed with the parameter set
to the changed value. A replay trial comparison report is then run for the two trials.
Guided Workflow: Create a SQL Performance Analyzer task and execute custom experiments
by using manually created replay trials.

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


Optimizer Upgrade Simulation

3 - 22 Copyright 2007, Oracle. All rights reserved.

Optimizer Upgrade Simulation


This page enables you to create a task that measures the performance impact on a SQL Tuning Set
when the database is upgraded from one version to another. In the example in the slide, the simulated
upgrade is done from 10.2.0.1 to 11.1.6. (You can go back to 8.0.0.)
To create an analysis task, you must specify the following details:
Enter the name of the task and (optionally) a description.
Specify the STS to use for this analysis. It must already be created.
Select the Per-SQL Time Limit from the list to specify the time limit for the execution of each
SQL statement:
- UNLIMITED: There is no time limit for the execution of each SQL statement.
- EXPLAIN ONLY: The test plan is generated but not executed.
- CUSTOMIZE: You can customize the execution time limit.
Select the Optimizer Versions to indicate the original version of the database and the new
version to which the database is being upgraded. Two replay trials are created. The first captures
STS performance with the original optimizer version, and the second uses the targeted version.
Select the Comparison Metric to be used to evaluate the performance impact due to the database
upgrade.
Specify the Schedule for the task.
Click Submit to proceed with the analysis.

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


SQL Performance Analyzer: Tasks

3 - 23 Copyright 2007, Oracle. All rights reserved.

SQL Performance Analyzer: Tasks


After you create your SQL Performance Analyzer task, it might take a long time for it to be executed
depending on the number of statements that are contained in your SQL Tuning Set. While your task
is executing, you can click Refresh on the SQL Performance Analyzer page until you see a green tick
in the Last Run Status column for your task in the SQL Performance Analyzer Tasks table.
After execution, you can click the link corresponding to the name of your task in the SQL
Performance Analyzer Tasks table. This directs you to the corresponding SQL Performance Analyzer
Task page.

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


SQL Performance Analyzer Task Page

3 - 24 Copyright 2007, Oracle. All rights reserved.

SQL Performance Analyzer Task Page


A SQL Performance Analyzer Task allows you to execute a specific SQL Tuning Set under changed
environmental conditions. After you execute the task, you can assess the impact of these changes on
the performance of the SQL Tuning Set. The Comparison Report is useful in assessing the impact of
the changed environmental conditions on the performance of the specified SQL Tuning Set.
From this page, you can also:
Create a Replay Trial to test the performance of a SQL Tuning Set under a specific environment.
Click Create Replay Trial. Refer to the Guided Workflow page for detailed information about
creating a Replay Trial.
Run a Replay Trial Comparison to compare the differences between the Replay Trials that have
been created so far. A Comparison Report is generated for each Replay Trial Run.
Click Run Replay Trial Comparison. Refer to the Guided Workflow page for detailed
information about running a Replay Trial Comparison.
Click the eyeglass icon in the Comparison Report column to view the Replay Trial Comparison
Report for your task.

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


Comparison Report

3 - 25 Copyright 2007, Oracle. All rights reserved.

Comparison Report
Use the SQL Performance Analyzer Task Result page to see the Replay Trial Comparison Report.
The following general details are displayed:
Task details such as name, owner, and description of the task
Name and owner of the SQL Tuning Set
Total number of SQL statements and any SQL statements with errors. Click the SQL Statements
With Errors link to access the Errors table.
The Replay Trials being compared and comparison metric being used
In addition to these details, you can view the following:
Projected Workload [Comparison Metric]: This chart shows the projected workload for each
Replay Trial based on the comparison metric along with the improvement, regression, and
overall impact. Click the impact links to drill down to the complete list of SQL statements in
each category.
SQL Statement Count: This chart shows the number of SQL statements that have improved,
regressed, or not changed performance based on the comparison metric. The colors of the bars
indicate whether the plan changed between the two trial runs. Click the links or the data buckets
to access the SQL Statement Count Details page, where you can see a list of SQL statements,
and then click a SQL ID to access the SQL details.
Top 10 SQL Statements Based on Impact on Workload table: This table allows you to
click a specific SQL ID to drill down to the corresponding SQL Details page.
Oracle Database 11g: New Features for Administrators 3 - 25
Comparison Report

3 - 26 Copyright 2007, Oracle. All rights reserved.

Comparison Report (continued)


On the SQL Details page, you can view the SQL statements and a line-by-line comparison between
each Replay Trial Run for each statistic. You can also find the explain plan for each trial.

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


Tuning Regressing Statements

3 - 27 Copyright 2007, Oracle. All rights reserved.

Tuning Regressing Statements


From the SQL Performance Analyzer Task Result page, you can directly tune all regressing
statements by invoking SQL Tuning Advisor. To do so, click the Run SQL Tuning Advisor button to
access the Schedule SQL Tuning Task page, where you can specify the tuning task name and a
schedule.
When you are finished, click OK. This creates a new tuning task that analyzes all regressing
statements found by SQL Performance Analyzer.

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


Tuning Regressing Statements

3 - 28 Copyright 2007, Oracle. All rights reserved.

Tuning Regressing Statements (continued)


After the SQL tuning task is created, you return to the SQL Performance Analyzer Task Result page,
where you can clearly see (in the Recommendations section) that you now have a tuning task
associated with your performance analysis.
Click the SQL Tune Report link to access the corresponding SQL Tuning Results page, where you
can see the Recommendations table that lists all recommendations for regressing statements.
You can also access the SQL Tuning Results page directly from the SQL Performance Analyzer Task
page by clicking the eyeglass icon in the SQL Tune Report column of the Replay Trial Comparisons
section for your trial comparison.

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


Preventing Regressions

3 - 29 Copyright 2007, Oracle. All rights reserved.

Preventing Regressions
Instead of using SQL Tuning Advisor to tune your regressing statements, you can also prevent
regressions by using the SQL plan baselines. You can do so from the SQL Performance Analyzer
Task Result page by clicking the Create SQL Plan Baselines button.
Note: For more information about SQL plan baselines, refer to the lesson titled SQL Plan
Manageability.

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


Parameter Change Analysis

3 - 30 Copyright 2007, Oracle. All rights reserved.

Parameter Change Analysis


Use the Parameter Change page to create a task that allows you to test the performance impact on a
SQL Tuning Set when the value of the initialization parameter is changed. This option is very useful
because it is difficult to forecast whether changing the parameter value will have a positive or
negative impact.
To create a task, do the following:
Enter the name of the task and a description.
Click the Select icon and select a SQL Tuning Set from the list.
Select the Per-SQL Time Limit from the list to specify the time limit for the execution of each
SQL statement.
Click the Select icon to select an initialization parameter from the list.
Specify the current value (Base Value) and the new value (Changed Value) for the initialization
parameter.
Select the comparison metric that will be used to evaluate the performance impact due to the
change.
Specify the schedule for the task.
After the task has been created, an initial trial run is performed with the initialization parameter set to
the Base Value. A second trial run is performed with the initialization parameter set to the Changed
Value. Finally, a Replay Trial Comparison report is generated for the two trials with the specified
comparison metric.
Oracle Database 11g: New Features for Administrators 3 - 30
Guided Workflow Analysis

3 - 31 Copyright 2007, Oracle. All rights reserved.

Guided Workflow Analysis


You can use the Guided Workflow page to define a sequence of steps to execute a two-trial SQL
Performance Analyzer test. The steps are as follows:
Create a SQL Performance Analyzer task based on a SQL Tuning Set.
Replay the SQL Tuning Set in the initial environment: Any changes to the trial environment that
affect the STS must be made manually before the Replay Trial is executed. These trials may
include changing initialization parameters, gathering optimizer statistics, and creating indexes.
Create the Replay Trial using the changed environment: You can now create the second Replay
Trial using the changed environment by specifying all the necessary information. Performance
differences between the trials are attributed to the environmental differences.
Create the Replay Trial Comparison using trials from previous steps: This allows you to assess
the performance impact on the STS when each Replay Trial is executed.
View the Trial Comparison Report: You can now generate the Replay Trial Comparison report.
Note: Before submitting a replay trial, you must select the Trial environment established option on
the corresponding task page. However, you must manually make the necessary changes.

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


SQL Performance Analyzer: PL/SQL Example
exec :tname:= dbms_sqlpa.create_analysis_task( -
sqlset_name => 'MYSTS', task_name => 'MYSPA');

exec dbms_sqlpa.execute_analysis_task(task_name => :tname, -


execution_type => 'TEST EXECUTE', execution_name => 'before');
select dbms_sqlpa.report_analysis_task(task_name => :tname,
type=>'text', section=>'summary') FROM dual;

Make changes

exec dbms_sqlpa.execute_analysis_task(task_name => :tname, -


execution_type => 'TEST EXECUTE', execution_name => 'after');
select dbms_sqlpa.report_analysis_task(task_name => :tname,
type=>'text', section=>'summary') FROM dual;

exec dbms_sqlpa.execute_analysis_task(task_name => :tname,


execution_type => 'COMPARE PERFORMANCE');
select dbms_sqlpa.report_analysis_task(task_name => :tname,
type=>'text', section=>'summary') FROM dual;

3 - 32 Copyright 2007, Oracle. All rights reserved.

SQL Performance Analyzer: PL/SQL Example


The general example in the slide shows you how to use the DBMS_SQLPA package to invoke SQL
Performance Analyzer to access the SQL performance impact of some changes. You could easily
adapt this example to run your own analysis.
1. Create the tuning task to run SQL Performance Analyzer.
2. Execute the task once to build the before-change performance data, and produce the before-
change report (special settings for report: set long 100000, longchunksize 100000,
and linesize 90). With this call, you can specify various parameters, some of which are:
- Set the execution_type parameter in either of the following ways: Set to EXPLAIN
PLAN to generate explain plans for all SQL statements in the SQL workload. Set to TEST
EXECUTE to execute all SQL statements in the SQL workload. The procedure executes
only the query part of the DML statements to prevent side-effects to the database or user
data. When TEST EXECUTE is specified, the procedure generates execution plans and
execution statistics.
- Specify execution parameters by using the execution_params parameter that needs to
be specified as dbms_advisor.arglist(name,value,). The time_limit
parameter specifies the global time limit to process all SQL statements in a SQL Tuning Set
before timing out. The local_time_limit parameter specifies the time limit to process
each SQL statement in a SQL Tuning Set before timing out.

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


SQL Performance Analyzer: PL/SQL Example (continued)
3. Make your changes.
4. Execute the task again after making the changes, and get the after-changes report.
5. Compare the two executions and get the analysis report. Using different execution parameters,
you can execute the following command:
EXEC DBMS_SQLTUNE.EXECUTE_TUNING_TASK( task_name => :tname, -
execution_type => 'compare performance', execution_params =>
dbms_advisor.arglist( 'execution_name1', 'before',
'execution_name2', 'after', 'comparison_metric', 'buffer_gets'));
Note: For more information about the DBMS_SQLPA package, see the Oracle Database PL/SQL
Packages and Types Reference Guide.

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


SQL Performance Analyzer:
Data Dictionary Views

Modified views in Oracle Database 11g:


DBA{USER}_ADVISOR_TASKS: Displays details about the
analysis task
DBA{USER}_ADVISOR_FINDINGS: Displays analysis
findings
New views in Oracle Database 11g:
DBA{USER}_ADVISOR_EXECUTIONS: Lists metadata
information for task execution
DBA{USER}_ADVISOR_SQLPLANS: Displays the list of SQL
execution plans
DBA{USER}_ADVISOR_SQLSTATS: Displays the list of SQL
compilation and execution statistics

3 - 34 Copyright 2007, Oracle. All rights reserved.

SQL Performance Analyzer: Data Dictionary Views


DBA{USER}_ADVISOR_SQLPLANS: Displays the list of all SQL execution plans (or those
owned by the current user)
DBA{USER}_ADVISOR_SQLSTATS: Displays the list of SQL compilation and execution
statistics (or those owned by the current user)
DBA{USER}_ADVISOR_TASKS: Displays details about the advisor task created to perform an
impact analysis of a system environment change
DBA{USER}_ADVISOR_EXECUTIONS: Lists metadata information for a task execution. SQL
Performance Analyzer creates a minimum of three executions to perform a change impact
analysis on a SQL workload: one execution to collect performance data for the before-change
version of the workload, the second execution to collect data for the after-change version of the
workload, and a final execution to perform the actual analysis.
DBA{USER}_ADVISOR_FINDINGS: Displays analysis findings. The advisor generates four
types of findings: performance regression, symptoms, errors, and informative messages.

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


Summary

In this lesson, you should have learned how to:


Identify the benefits of using SQL Performance
Analyzer
Describe the SQL Performance Analyzer workflow
phases
Use SQL Performance Analyzer to determine
performance gains following a database change

3 - 35 Copyright 2007, Oracle. All rights reserved.

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


Practice 3: Overview

This practice covers the following topics:


Capturing SQL Tuning Sets
Migrating SQL Tuning Sets from Oracle Database 10g
to Oracle Database 11g
Using SQL Performance Analyzer in an upgrade
scenario

3 - 36 Copyright 2007, Oracle. All rights reserved.

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


SQL Plan Management

Copyright 2007, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to:


Set up SQL Plan Management
Set up various SQL Plan Management scenarios

4-2 Copyright 2007, Oracle. All rights reserved.

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


SQL Plan Management: Overview

SQL Plan Management is automatically controlled SQL


plan evolution.
Optimizer automatically manages SQL plan baselines.
Only known and verified plans are used.
Plan changes are automatically verified.
Only comparable or better plans are used going forward.
Can pre-seed critical SQL with STS from SQL
Performance Analyzer

4-3 Copyright 2007, Oracle. All rights reserved.

SQL Plan Management: Overview


Potential performance risk occurs when the SQL execution plan changes for a SQL statement.
A SQL plan change can occur due to a variety of reasons like optimizer version, optimizer statistics,
optimizer parameters, schema definitions, system settings, and SQL profile creation.
Various plan control techniques (such as stored outlines and SQL profiles) have been introduced in
the past versions of Oracle Database to address performance regressions due to plan changes.
However, these techniques are reactive processes that require manual intervention.
SQL Plan Management is a new feature introduced with Oracle Database 11g that enables the system
to automatically control SQL plan evolution by maintaining what is called SQL plan baselines. With
this feature enabled, a newly generated SQL plan can integrate a SQL plan baseline only if it has
been proven that doing so will not result in performance regression. So, during execution of a SQL
statement, only a plan that is part of the corresponding SQL plan baseline can be used. As described
later in this lesson, SQL plan baselines can be automatically loaded or can be seeded using SQL
Tuning Sets. Various scenarios are covered later in this lesson.
The main benefit of the SQL Plan Management feature is the performance stability of the system
through the avoidance of plan regressions. In addition, it saves the DBA time that is often spent in
identifying and analyzing SQL performance regressions and finding workable solutions.

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


SQL Plan Baseline: Architecture
SYSAUX
SQL Management Base

Statement log

Plan history
Plan history
Plan
baseline Plan
GB baseline
GB GB GB
HJ GB GB SQL
HJ HJ HJ HJ HJ HJ profile
Repeatable HJ HJ HJ
HJ HJ
SQL
statement

Plan History

Plan
baseline
GB
GB GB
HJ
HJ HJ HJ
HJ HJ Automatic
SQL Tuning
task
Plan verification before
integration to baseline

4-4 Copyright 2007, Oracle. All rights reserved.

SQL Plan Baseline: Architecture


The SQL Plan Management (SPM) feature introduces necessary infrastructure and services in
support of plan maintenance and performance verification of new plans.
For SQL statements that are executed more than once, the optimizer maintains a history of plans for
individual SQL statements. The optimizer recognizes a repeatable SQL statement by maintaining a
statement log. A SQL statement is recognized as repeatable when it is parsed or executed again after
it has been logged. After a SQL statement is recognized as repeatable, various plans generated by the
optimizer are maintained as a plan history containing relevant information (such as SQL text, outline,
bind variables, and compilation environment) that is used by the optimizer to reproduce an execution
plan.
As an alternative or complement to the automatic recognition of repeatable SQL statements and the
creation of their plan history, manual seeding of plans for a set of SQL statements is also supported.
A plan history contains different plans generated by the optimizer for a SQL statement over time.
However, only some of the plans in the plan history may be accepted for use. For example, a new
plan generated by the optimizer is not normally used until it has been verified not to cause a
performance regression. Plan verification is done out of the box as part of Automatic SQL Tuning
running as an automated task in a maintenance window.

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


SQL Plan Baseline: Architecture (continued)
An Automatic SQL Tuning task targets only high-load SQL statements. For them, it automatically
implements actions such as making a successfully verified plan an accepted plan. A set of acceptable
plans constitutes a SQL plan baseline. The very first plan generated for a SQL statement is obviously
acceptable for use; therefore, it forms the original plan baseline. Any new plans subsequently found
by the optimizer are part of the plan history but not part of the plan baseline initially.
The statement log, plan history, and plan baselines are stored in the SQL Management Base (SMB),
which also contains SQL profiles. The SMB is part of the database dictionary and is stored in the
SYSAUX tablespace. The SMB has automatic space management (for example, periodic purging of
unused plans). You can configure the SMB to change the plan retention policy and set space size
limits.
Note: With Oracle Database 11g, if the database instance is up but the SYSAUX tablespace is
OFFLINE, the optimizer is unable to access SQL management objects. This can affect performance
on some of the SQL workload.

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


Loading SQL Plan Baselines
OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES=TRUE dbms_spm
Plan history
Plan history ba
an se

load_plans_from_cursor_cache
ba Pl lin
e
GB
an se
Pl lin

load_plans_from_sqlset
1 e HJ

HJ

GB
HJ

HJ

GB alter_sql_plan_baseline
HJ
2
HJ
*_stgtab_baseline

GB
HJ 3
HJ Staging
Cursor table
cache
Plan history
ba
an se
Pl GB lin
e 4
HJ

HJ
DBA

4-6 Copyright 2007, Oracle. All rights reserved.

Loading SQL Plan Baselines


There are two ways to load SQL plan baselines.
On the fly capture: Uses automatic plan capture by setting the initialization parameter
OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES to TRUE. This parameter is set to FALSE
by default. Setting it to TRUE turns on automatic recognition of repeatable SQL statements and
automatic creation of plan history for such statements. This is illustrated in the left graphic in the
slide, where you can see the first generated SQL plan automatically integrated into the original
SQL plan baseline.
Bulk loading: Uses the DBMS_SPM package, which enables you to manually manage SQL plan
baselines. With this package, you can load SQL plans into a SQL plan baseline directly from the
cursor cache or from an existing SQL Tuning Set (STS). For a SQL statement to be loaded into a
SQL plan baseline from an STS, the SQL statement needs to store its SQL plan in the STS.
DBMS_SPM enables you to change the status of a baseline plan from accepted to not accepted
(and from not accepted to accepted). It also enables you to export baseline plans from a staging
table, which can then be used to load SQL plan baselines on other databases.

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


Evolving SQL Plan Baselines

variable report clob


exec :report:=DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE(sql_handle=>'SYS_SQL_593bc74fca8e6738');
Print report

Plan history
ba
an se
Automatic Pl lin
e
GB
SQL Tuning HJ

HJ
DBA GB
HJ

HJ
>?

SQL
Tuning
Advisor

4-7 Copyright 2007, Oracle. All rights reserved.

Evolving SQL Plan Baselines


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

Plan history
ba
an se
GB
Pl lin
e
GB
Enabled but HJ
Enabled and
HJ
not accepted HJ HJ
accepted

select signature, sql_handle, sql_text, plan_name, origin, enabled,


accepted, fixed, autopurge
from dba_sql_plan_baselines;

SIGNATURE SQL_HANDLE SQL_TEXT PLAN_NAME ORIGIN ENA ACC FIX AUT


--------- ------------ -------- ---------------- ------------ --- --- --- ---
8.062E+18 SYS_SQL_6fe2 select.. SYS_SQL_PLAN_1ea AUTO-CAPTURE YES NO NO YES
8.062E+18 SYS_SQL_6fe2 select.. SYS_SQL_PLAN_4be AUTO-CAPTURE YES YES NO YES

exec :cnt := dbms_spm.alter_sql_plan_baseline(sql_handle => 'SYS_SQL_37e0168b03efe', -


plan_name => 'SYS_SQL_PLAN_8dfc352f359901ea', -
attribute_name => 'ENABLED', attribute_value => 'NO');

4-8 Copyright 2007, Oracle. All rights reserved.

Important Baseline SQL Plan Attributes


When a plan enters the plan history, it is associated with a number of important attributes:
SIGNATURE, SQL_HANDLE, SQL_TEXT, and PLAN_NAME are important identifiers for
search operations.
ORIGIN allows you to determine whether the plan was automatically captured (AUTO-
CAPTURE), manually evolved (MANUAL-LOAD), automatically evolved by SQL Tuning
Advisor (MANUAL-SQLTUNE), or automatically evolved by Automatic SQL Tuning (AUTO-
SQLTUNE).
ENABLED and ACCEPTED: The ENABLED attribute means that the plan is enabled for use by
the optimizer. If ENABLED is not set, the plan is not considered. The ACCEPTED attribute
means that the plan was validated as a good plan, either automatically by the system or manually
when the user changes it to ACCEPTED. When a plan changes to ACCEPTED, it will become not
ACCEPTED only when DBMS_SPM.ALTER_SQL_PLAN_BASELINE() is used to change its
status. An ACCEPTED plan can be temporarily disabled by removing the ENABLED setting. A
plan must be ENABLED and ACCEPTED for the optimizer to consider using it.
FIXED means that the optimizer considers only those plans and not other plans. For example, if
you have 10 baseline plans and three of them are marked FIXED, the optimizer uses only the
best plan from these three, ignoring all the others. A SQL plan baseline is said to be FIXED if it
contains at least one enabled fixed plan. If new plans are added to a fixed SQL plan baseline,
these new plans cannot be used until they are manually declared as FIXED.

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


Important Baseline SQL Plan Attributes (continued)
You can look at each plans attributes by using the DBA_SQL_PLAN_BASELINES view, as shown
in the slide. You can then use the DBMS_SPM.ALTER_SQL_PLAN_BASELINE function to change
some of them. You can also remove plans or a complete plan history by using the
DBMS_SPM.DROP_SQL_PLAN_BASELINE function. The example shown in the slide changes the
ENABLED attribute of SYS_SQL_PLAN_8DFC352F359901EA to NO.
Note: The DBA_SQL_PLAN_BASELINES view contains additional attributes that enable you to
determine when each plan was last used and whether a plan should be automatically purged.

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


SQL Plan Selection
dbms_xplan.display_sql_plan_baseline

GB optimizer_use_ Plan part


HJ plan_baselines=true? Yes of history? No
HJ

Plan history
Yes
Plan
No
baseline
GB
GB GB
HJ
GB
HJ HJ HJ
Plan part HJ HJ
HJ
Yes of baseline?
HJ

No

Select baseline plan


with lowest best-cost

GB GB GB GB
Yes No
dbms_xplan.display(,'BASIC +NOTE) HJ HJ > HJ HJ
or HJ HJ HJ HJ
plan_table(other_xml)

4 - 10 Copyright 2007, Oracle. All rights reserved.

SQL Plan Selection


If you are using automatic plan capture, the first time that a SQL statement is recognized as
repeatable, its best-cost plan is added to the corresponding SQL plan baseline. That plan is then used
to execute the statement.
The optimizer uses a comparative plan selection policy when a plan baseline exists for a SQL
statement and the initialization parameter OPTIMIZER_USE_SQL_PLAN_BASELINES is set to
TRUE (default value). Each time a SQL statement is compiled, the optimizer first uses the traditional
cost-based search method to build a best-cost plan. Then it tries to find a matching plan in the SQL
plan baseline. If a match is found, it proceeds as usual. If no match is found, it first adds the new plan
to the plan history, then costs each of the accepted plans in the SQL plan baseline, and picks the one
with the lowest cost. The accepted plans are reproduced using the outline that is stored with each of
them. So the effect of having a SQL plan baseline for a SQL statement is that the optimizer always
selects one of the accepted plans in that SQL plan baseline.
With SQL Plan Management, the optimizer can produce a plan that could be either a best-cost plan
or a baseline plan. This information is dumped in the other_xml column of the plan_table
upon explain plan.
In addition, you can use the new dbms_xplain.display_sql_plan_baseline function to
display one or more execution plans for the specified sql_handle of a plan baseline. If
plan_name is also specified, the corresponding execution plan is displayed.

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


SQL Plan Selection (continued)
Note: To preserve backward compatibility, if a stored outline for a SQL statement is active for the
user session, the statement is compiled using the stored outline. In addition, a plan generated by the
optimizer using a stored outline is not stored in the SMB even if automatic plan capture has been
enabled for the session.
Although there is no explicit migrate procedure for stored outlines, they can be migrated to SQL plan
baselines by using the LOAD_PLAN_FROM_CURSOR_CACHE or LOAD_PLAN_FROM_SQLSET
procedures from the DBMS_SPM package. When the migration is complete, you should disable or
drop the original stored outline.

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


Possible SQL Plan Manageability Scenarios
Database Upgrade New Application Deployment
Oracle Database 11g Production database
Plan History Plan History
ba ba
an s an se
GB Pl GB eline GB Pl GB lin
e
HJ HJ HJ HJ

HJ HJ HJ HJ

No plan No plan
regressions regressions

DBA

DBA Plan history


ba
an s
GB Pl GB eline

GB HJ HJ
Well-
tuned HJ HJ HJ
plan HJ Well-tuned Baseline
plan plans
staging table
Oracle Database 10g Development database

4 - 12 Copyright 2007, Oracle. All rights reserved.

Possible SQL Plan Manageability Scenarios


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

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


SQL Performance Analyzer and
SQL Plan Baseline Scenario

Before Oracle Database 11g


change O_F_E=10
Plan History
ba
an s
Pl GB eline GB
HJ HJ

HJ HJ
Regressing
statements No plan
regressions
After
change
O_F_E=11

optimizer_features_enable

GB GB GB
HJ HJ HJ

HJ HJ HJ Well-
tuned
plans
Oracle Database 10g

4 - 13 Copyright 2007, Oracle. All rights reserved.

SQL Performance Analyzer and SQL Plan Baseline Scenario


A variation of the first method described in the previous slide is through the use of SQL Performance
Analyzer. You can capture preOracle Database 11g plans in an STS and import them into Oracle
Database 11g. Then set the initialization parameter optimizer_features_enable to 10g to
make the optimizer behave as if this were a 10g Oracle database. Next run SQL Performance
Analyzer for the STS. When that is complete, set the initialization parameter
optimizer_features_enable back to 11g and rerun SQL Performance Analyzer for the STS.
SQL Performance Analyzer produces a report that lists a SQL statement whose plan has regressed
from 10g to 11g. For those SQL statements that are shown by SQL Performance Analyzer to incur
performance regression due to the new optimizer version, you can capture their plans using an STS
and then load them into the SMB.
This method represents the best form of the plan-seeding process because it helps prevent
performance regressions while preserving performance improvements upon database upgrade.

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


Loading a SQL Plan Baseline Automatically
Oracle Database 11g No plan Oracle Database 11g No plan
regressions regressions
Plan history New plan Plan history
waiting
Plan verification Plan
baseline baseline
GB GB
GB GB GB
HJ HJ
HJ HJ HJ
HJ HJ
HJ HJ HJ

optimizer_features_enable=10.2.0.2 optimizer_features_enable=11.1.0.1
optimizer_capture_plan_baselines=true optimizer_capture_plan_baselines=true

Oracle Database 11g Better


plans
Plan history

Plan baseline
GB GB GB
GB
GB Well- HJ HJ HJ
HJ tuned
HJ HJ HJ HJ
HJ plans
HJ

Oracle Database 10g optimizer_features_enable=11.1.0.1


optimizer_capture_plan_baselines=true

4 - 14 Copyright 2007, Oracle. All rights reserved.

Loading a SQL Plan Baseline Automatically: Scenario


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

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


Purging SQL Management Base Policy

SQL> exec dbms_spm.configure('SPACE_BUDGET_PERCENT',20);


SQL> exec dbms_spm.configure('PLAN_RETENTION_WEEKS',105);

DBA_SQL_MANAGEMENT_CONFIG

time Alert log

105 SQL Management SYSAUX


Base

53

1% 10% 20% 50% space

SQL> exec :cnt := dbms_spm.drop_sql_plan_baseline('SYS_SQL_37e0168b04e73efe');

4 - 15 Copyright 2007, Oracle. All rights reserved.

Purging SQL Management Base Policy


The space occupied by the SQL Management Base (SMB) is checked weekly against a defined limit.
A limit based on the percentage size of the SYSAUX tablespace is defined. By default, the space
budget limit for the SMB is set to 10 percent of SYSAUX size. However, you can configure SMB and
change the space budget to a value between 1 percent and 50 percent by using the
DBMS_SPM.CONFIGURE procedure.
If SMB space exceeds the defined percent limit, warnings are written to the alert log. Warnings are
generated weekly until the SMB space limit is increased, the size of SYSAUX is increased, or the size
of SMB is decreased by purging some of the SQL management objects (such as SQL plan baselines
or SQL profiles).
The space management of SQL plan baselines is done proactively using a weekly purging task. The
task runs as an automated task in the maintenance window. Any plan that has not been used for more
than 53 weeks is purged. However, you can configure SMB and change the unused plan retention
period to a value between 5 weeks and 523 weeks (a little more than 10 years). To do so, use the
DBMS_SPM.CONFIGURE procedure.
You can look at the current configuration settings for the SMB by examining the
DBA_SQL_MANAGEMENT_CONFIG view. In addition, you can manually purge the SMB by using
the DBMS_SPM.DROP_SQL_PLAN_BASELINE function (as shown in the example in the slide).

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


Enterprise Manager and SQL Plan Baselines

4 - 16 Copyright 2007, Oracle. All rights reserved.

Enterprise Manager and SQL Plan Baselines


Use the SQL Plan Management page to manage SQL profiles, SQL patches, and SQL plan baselines
from one location rather than separate locations in Enterprise Manager. You can also enable, disable,
drop, pack, unpack, load, and evolve selected baselines.
From this page, you can also configure the various SQL plan baseline settings.

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


Summary

In this lesson, you should have learned how to:


Set up SQL Plan Management
Set up various SQL Plan Management scenarios

4 - 17 Copyright 2007, Oracle. All rights reserved.

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


Practice 4: Overview

This practice covers the use of SQL Plan Management.

4 - 18 Copyright 2007, Oracle. All rights reserved.

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


Database Replay

Copyright 2007, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to:


Identify the benefits of using Database Replay
List the steps involved in Database Replay
Use Enterprise Manager to record and replay
workloads

5-2 Copyright 2007, Oracle. All rights reserved.

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


Why Use Database Replay?

System changes (such as hardware and software upgrades)


are a fact of life.
Customers want to identify the full impact of changes before
going live.
Extensive testing and validation can be expensive in time
and money.
Despite expensive testing, success rates are low:
Many issues go undetected.
Changes can negatively affect system availability and
performance.
Cause of low success rate:
Inability to properly test with real-world production workloads,
with many issues going undetected.
The Database Replay feature makes it possible to do
real-world testing.

5-3 Copyright 2007, Oracle. All rights reserved.

Why Use Database Replay?


Large business-critical applications are complex and experience highly varying load and usage
patterns. At the same time, these business systems are expected to provide certain service-level
guarantees in terms of response time, throughput, uptime, and availability. Often any change to a
system, such as upgrading the database or modifying the configuration, necessitates extensive testing
and validation before these changes can make it to the production system. To be confident before
moving to a production system, the DBA needs to expose a test system to a workload very similar to
the workload to be experienced in a production environment. It is also beneficial for the DBA to have
an effective means of analyzing the impact of system-level changes on overall SQL performance so
that any tuning changes required can be performed before production.

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


Database Replay

Re-create actual production database workload in test


environment.
Identify and analyze potential instabilities before making
changes to production.
Capture workload in production:
Capture full production workload with real load & concurrency
Move the captured workload to test system
Replay workload in test:
Make the desired changes in test system
Replay workload with production load & concurrency
Honor commit ordering
Analyze and report:
Errors
Data divergence
Performance divergence

5-4 Copyright 2007, Oracle. All rights reserved.

Database Replay
Oracle Database 11g provides specific solutions to the challenges described in the preceding slides.
Database Replay allows you to test the impact of a system change by replaying real-world workload
on the test system before it is exposed to a production system. The production workload (including
transaction concurrency and dependency) of the database server is recorded over an illustrative
period of time (for example, a peak period). This recorded data is used to replay the workload on a
test system that has been appropriately configured. You gain a high degree of confidence in the
overall success of the database change by subjecting the database server in a test system to a
workload that is practically indistinguishable from a production workload.

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


System Architecture: Capture

Capture directory

Shadow capture file


Shadow Shadow Shadow Shadow

Shadow capture file


Recording infrastructure
Database stack Shadow capture file

Shadow capture file


Background Background

Database
backup

Production
database

5-5 Copyright 2007, Oracle. All rights reserved.

System Architecture: Capture


Here you see an illustration of a system that is being recorded. You should always record a workload
that spans an interesting period in a production system. Typically, the replay of the recording is
used to determine whether it is safe to upgrade to a new version of the RDBMS server. A special
recording infrastructure built into the RDBMS records data about all external client requests while
the production workload is running on the system. External requests are any SQL queries, PLSQL
blocks, PLSQL remote procedure calls, DML statements, DDL statements, Object Navigation
requests, or OCI calls. During the recording, background jobs and, in general, all internal clients
continue their work without being recorded. The end product is a workload recording containing all
necessary information for replaying the workload as seen by the RDBMS in the form of external
requests.
The recording infrastructure imposes minimal performance overhead (extra CPU, memory, and I/O)
on the recording system. You should, however, plan to accommodate the additional disk space
needed for the actual workload recording.
RAC Note: Instances in a RAC environment have access to the common database files. However,
they do not need to share a common general-purpose file system. In such an environment, the
workload recording is written on each instances file system during recording. For processing and
replay, all parts of the workload recording need to be manually copied into a single directory.

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


System Architecture: Processing the Workload

Capture directory

Process capture files


Shadow capture file

Shadow capture file

Database stack Shadow capture file

Shadow capture file


Background Background

Database
backup

Production
Process
database capture

5-6 Copyright 2007, Oracle. All rights reserved.

System Architecture: Processing the Workload


The workload capture data is processed, and new workload replay-specific metadata files are created
that are required for the replay of the given workload capture. Only new files are created; no files are
modified that were created during the workload capture. Because of this, you can run the preprocess
multiple times on the same capture directory (for example, when the procedure encounters
unexpected errors or is canceled).
External client connections are remapped at this stage. Any replay parameters that affect the replay
outcome can be modified.
Note: Because processing workload capture can be relatively expensive, the best practice is to do
that operation on a system other than the production database system.

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


System Architecture: Replay
Replay
system Replay Replay
client client
Capture directory

Process capture files


Shadow Shadow Shadow Shadow
Shadow capture file

Shadow capture file

Database stack Shadow capture file

Shadow capture file


Background Background

Test
system
with
Database changes
backup

Test
database

5-7 Copyright 2007, Oracle. All rights reserved.

System Architecture: Replay


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

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


5-8 Copyright 2007, Oracle. All rights reserved.

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


Pre-Change Production System

Changes not supported


Clients/app servers

Supported changes
Database upgrades, patches
Production
Schema, parameters system

RAC nodes, interconnect


OS platforms, OS upgrades
CPU, memory Production
Storage database

5-9 Copyright 2007, Oracle. All rights reserved.

Pre-Change Production System


Database Replay focuses on recording and replaying the workload that is directed to the RDBMS.
Therefore, recording the workload is done at the point indicated in the diagram in the slide.
Recording at the RDBMS in the software stack makes it possible to exchange anything below this
level and test the new setup using the record-and-replay functionality.
While replaying the workload, the RDBMS performs the actions observed during recording. In other
words, during the replay phase the RDBMS code is exercised in a way that is very similar to the way
it was exercised during the recording phase. This is achieved by re-creating all external client
requests to the RDBMS. External client requests include all the requests by all possible external
clients of the RDBMS.

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


Supported Workloads

Supported
All SQL (DML, DDL, PL/SQL) with practically all types of binds
Full LOB functionality (cursor-based and direct OCI)
Local transactions
Logins and logoffs
Session switching
Limited PL/SQL RPCs
Limitations
Direct path load, import/export
OCI-based object navigation (ADTs) and REF binds
Streams, non-PL/SQL-based AQ
Distributed txns, remote describe/commit operations
Flashback (Database and Query)
Shared Server

5 - 10 Copyright 2007, Oracle. All rights reserved.

Supported Workloads
The slide shows supported and nonsupported database operations.

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


Capture Considerations
Planning
Adequate disk space for captured workload (binary files)
Database restart:
Only way to guarantee authentic replay
Startup restrict
Capture will un-restrict
May not be necessary depending on the workload
A way to restore database for replay purposes:
Physical restore (scn/time provided)
Logical restore of application data
Flashback/snapshot-standby
Filters can be specified to capture subset of the workload.
SYSDBA or SYSOPER privileges and appropriate OS privileges
Overhead
Performance overhead for TPCC is 4.5%
Memory overhead : 64 KB per session
Disk space

5 - 11 Copyright 2007, Oracle. All rights reserved.

Capture Considerations
You perform the following tasks in the planning phase of the workload recording:
Check the database backup strategy, ensuring that the database can be restored to StartSCN
when the recording starts.
Plan the capture period by selecting it based on the application and the peak periods. You can
use existing manageability features such as Automatic Workload Repository (AWR) and Active
Session History (ASH) to select an appropriate period based on workload history. The starting
time for capture should be carefully planned because it is recommended that you shut down and
restart the database before starting the capture.
Specify the location of the workload capture data. You must set up a directory that is to be used
to store the workload capture data. You should provide ample disk space because the recording
stops if there is insufficient disk space. However, everything captured up to that point is usable
for replay.
Define capture filters for user sessions that are not to be captured. You can specify a recording
filter to skip sessions that should not be captured.
No new privileges or user roles are introduced with the Database Replay functionality. The
recording user and replay user must have either the SYSDBA or SYSOPER privilege. This is
because a user having only SYSOPER or SYSDBA can start up or shut down the database to start
the recording. Correct operating system (OS) privileges should also be assigned so that the user
is able to access the recording, replay directories, and manipulate the files under those
directories.
Oracle Database 11g: New Features for Administrators 5 - 11
Replay Considerations

Preprocess captured workload


One-time action
On same DB version as replay
Can be performed anywhere (production, test system, or
other system) if versions match
Restore database, and then perform the change:
Upgrade
Schema changes
OS change
Hardware change
Add instance

5 - 12 Copyright 2007, Oracle. All rights reserved.

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

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


Replay Considerations

Manage external interactions


Remap connection strings to be used for the workload:
One-to-one: For simple instance-to-instance remapping
Many-to-one: Use of load balancer (e.g., single node to RAC)
Modify DB Links and directory objects that point to
production systems
Set up one or more replay clients
Multithreaded clients that can each drive multiple
workload sessions

5 - 13 Copyright 2007, Oracle. All rights reserved.

Replay Considerations (continued)


A captured workload may contain references to external systems that are meaningful only in the
capture environment. Replaying a workload with unresolved references to external systems may
cause unexpected problems in the production environment.
A replay should be performed in a completely isolated test environment. You should make sure that
all references to external systems have been resolved in the replay environment such that replaying a
workload will cause no harm to your production environment.
You can make one-to-one or many-to-one remappings. For example, database links in a captured
production environment may reference external production databases that should not be referenced
during replay. Therefore, you should modify any external references that could jeopardize the
production environment during replay.
The replay client (an executable named wrc) submits a captured sessions workload. You should
install one or more replay clients, preferably on systems other than the production host. Each replay
client must be able to access the directory that holds the preprocessed workload.
You can also modify the replay parameters to change the behavior of the replay.

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


Replay Options

Synchronized replay:
Ensures minimal data divergence
Commit-based synchronization
Unsynchronized replay:
Useful for load/stress testing
Original commit ordering not honored
High data divergence
Think time options:
Auto (default)
Adjust think time to maintain the captured request rate:
0%: No think time (highest possible request rate)
<100%: Higher request rate
100%: Exact think time
>100%: Lower request rate
Login time options
Percentage (default is 100%)

5 - 14 Copyright 2007, Oracle. All rights reserved.

Replay Options
The following replay options can be modified while replaying your workload:
The synchronization parameter determines whether synchronization will be used during
workload replay. If this parameter is set to TRUE, the COMMIT order in the captured workload
will be preserved during replay and all replay actions will be executed only after all dependent
COMMIT actions have completed. The default value is TRUE.
The think_time_scale parameter scales the elapsed time between two successive user
calls from the same session; it is interpreted as a percentage value. Use this parameter to
increase or decrease the replay speed. Setting this parameter to 0 will send user calls to the
database as fast as possible during replay. The default value is 100.
The think_time_auto_correct parameter corrects the think time (based on the
think_time_scale parameter) between calls, when user calls take longer to complete
during replay than during capture. It is interpreted as a percentage value.
The connect_time_scale parameter scales the elapsed time from when the workload
capture started to when the session connects with the specified value; it is interpreted as a
percentage. Use this option to manipulate the session connect time during replay. The default
value is 100.
Note: During workload capture, elapsed time is measured by user time and user think time. User
time is the elapsed time of a user call to the database. User think time is the elapsed time while the
user waits between issuing calls. During workload replay, elapsed time is measured by user time,
user think time, and synchronization time.
Oracle Database 11g: New Features for Administrators 5 - 14
Replay Analysis

Data divergence
Number of rows compared for each call (queries, DML)
Error divergence
New errors
Mutated errors
Errors that have disappeared
Performance
Capture and Replay report
ADDM report
ASH report for skew analysis
AWR report

5 - 15 Copyright 2007, Oracle. All rights reserved.

Replay Analysis
There may be some divergence of the replay compared to what was recorded. For example, when
replaying on a newer version of the RDBMS, a new algorithm may cause specific requests to be
faster, resulting in divergence appearing as a faster execution. This is considered a desirable
divergence. Another example of a divergence is when a SQL statement returns fewer rows during
replay than those returned during recording. This is clearly undesirable.
For data divergence, the result of an action can be considered as:
The result set of SQL query
An update to persistent database state
A return code or error code
Performance divergence is useful in determining how new algorithms introduced in the replay
system may affect overall performance. There are numerous factors that can cause replay divergence.
Though some of them cannot be controlled, others can be mitigated. It is the task of the DBA to
understand the workload run-time operations and take the necessary actions to reduce the level of
record-and-replay divergence.
Online divergence should aid the decision to stop a replay that has diverged significantly. The results
of the replay before the divergence may still be useful, but further replay would not produce reliable
conclusions. Offline divergence reporting is used to determine how successful the replay was after
the replay has finished.

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


Replay Analysis (continued)
Data divergence of the replay encompasses the results of both queries and errors. That is, errors that
occurred during recording are considered proper results and any change during replay is reported.
You can use existing tools such as ADDM to measure performance differences between the
recording system and the replay system.
Additionally, error comparison reports during the replay report on the following:
Errors that did not happen during recording
Errors that were not reproduced during replay
Difference in error type

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


Database Replay Workflow in Enterprise Manager

1. Capture the workload on a database. (Task 1)


2. Optionally export the AWR data. (Task 1)
3. Restore the replay database on a test system.
4. Make changes to the test system as required.
5. Copy the workload to the test system.
6. Preprocess the captured workload. (Task 2)
7. Configure the test system for the replay.
8. Replay the workload on the restored database. (Task 3)

5 - 17 Copyright 2007, Oracle. All rights reserved.

Database Replay Workflow in Enterprise Manager


The following are the typical steps to perform Database Replay. Steps done with Enterprise Manager
(EM) are marked as Task n. Other steps are not part of the EM workflow:
1. Capture the workload on a database. (Task 1)
2. Optionally export the AWR data. (Task 1)
3. Restore the replay database on a test system to match the capture database at the start of the
workload capture.
4. Make changes (such as performing an upgrade) to the test system as required.
5. Copy the generated workload files to the test system.
6. Preprocess the captured workload on the test system. (Task 2)
7. Configure the test system for the replay.
8. Replay the workload on the restored database. (Task 3)

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


Capturing Workload with Enterprise Manager

5 - 18 Copyright 2007, Oracle. All rights reserved.

Capturing Workload with Enterprise Manager


Enterprise Manager (EM) provides you with a user interface to manage each component in the
Database Replay process. The workflow and user interface applies to both EM Database Control and
EM Grid Control.
You access Database Replay on the Software and Support tab of Database Control.
On the Database Replay page, you can perform the following named tasks:
Capture Workload
Preprocess Capture Workload
Replay Workload
View Workload Capture History: Click this link to view or delete the history of all workload
captures.
Active Capture and Replay: If a capture or replay is currently in progress, this table appears at
the bottom of the page even if there are no rows. To view the status of the capture or replay,
select the name and click View, or just click the Name link.
RAC Note: When an instance goes down during capture of a RAC system, the capture continues
normally and is not aborted. The sessions that died as a result of an instance going down will be
replayed up to the point at which the instance died. When a dead instance is repaired and comes up
again during capture, all new sessions are recorded normally. During replay, the death of instances is
not replayed.

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


Using the Capture Wizard

5 - 19 Copyright 2007, Oracle. All rights reserved.

Using the Capture Wizard


On the Capture Workload: Plan Environment page, select each of the Acknowledge check boxes
after you have met the prerequisites. If you do not handle the prerequisites, the following problems
can occur:
Not restarting the database could capture in-flight transactions, which may adversely affect the
replay of subsequent captured transactions.
The captured workload will be written to the file system and can use up all the available disk
space.
The chance of error and data divergence increases if application data does not match at the start
of capture and replay.
When you are finished, click Next to proceed with the rest of the wizard.
Note: You can choose to restart the database before capture begins. Be sure that all other database
activities can be temporarily stopped.

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


Using the Capture Wizard

5 - 20 Copyright 2007, Oracle. All rights reserved.

Using the Capture Wizard (continued)


On the Capture Workload: Options page, you can do the following:
Choose whether to restart the database before starting capture. You do this in the Database
Restart Options section. If the database is not restarted before capture begins, some database
activities may not be captured accurately and completely. During replay, these incompletely
captured activities may cause the replay database state to diverge from the capture database. The
replay reports errors in these cases.
Define workload filters in the Workload Filters section. Decide whether you want to include or
exclude certain sessions, and then provide filter names, corresponding session attributes, and
values. Selecting Inclusion as the filter mode captures only what you specify, and selecting
Exclusion captures everything except what you specify. You can either include or exclude
certain sessions, but you cannot do both at the same time. The default filter names exclude
Enterprise Manager activities. The Value column represents the actual name for the session
attribute, whereas you can provide any filter name desired.
When you are finished, click Next to proceed with the rest of the wizard.

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


Using the Capture Wizard

5 - 21 Copyright 2007, Oracle. All rights reserved.

Using the Capture Wizard (continued)


On the Capture Workload: Parameters page, you can either provide your own required capture
name or accept the system-supplied name. Select a directory object name from the list of existing
directory objects defined in the system, or click Create Directory Object to specify a unique name
and path for a new directory object. This directory is used to generate the capture files.
Then click Next. This takes you to the Capture Workload: Schedule page, where you can either
provide your own required job name or accept the system-supplied name. The job system
automatically names the job in uppercase. The job and capture names do not have to match.
If you schedule the job immediately and if you specified restarting the database in the Options step,
the Information: Restart Database page appears after you submit the job in the Review step, and
then the View Workload Capture page appears. If you schedule the job for a later time with or
without a restart, the Database Replay page appears with a message notifying you that a job has been
scheduled after you submit the job in the Review step. If you do not specify a capture duration, you
must manually stop capture by clicking the Stop button on the Database Replay page while capture is
in progress. You can also stop capture on the View Workload Capture page.
Click Next to go to the Review page, where you can verify that the settings are as you intended
before you submit the job.
RAC Note: For RAC, the DBA should define the directory for captured data at a storage location
accessible by all instances. Otherwise, the workload capture data needs to be copied from all
locations to a single location before starting the processing of the workload recording.
Oracle Database 11g: New Features for Administrators 5 - 21
Using the Capture Wizard

5 - 22 Copyright 2007, Oracle. All rights reserved.

Using the Capture Wizard (continued)


The slide illustrates the case in which you schedule the capture job immediately, do not specify
restarting the database in the Options step, and do not indicate a capture duration.
Capture is now in effect, and you must manually stop capture by clicking the Stop Capture button on
the View Workload Capture page.
At this point, you must run your workload.

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


Using the Capture Wizard

5 - 23 Copyright 2007, Oracle. All rights reserved.

Using the Capture Wizard (continued)


Use the View Workload Capture page to see the progress of a workload capture that you have
initiated, or to see historical information about the capture after it has completed execution. This
page is available from the Active Capture and Replay table on the Database Replay home page,
from the View Capture History page (for a completed capture), or after a nonscheduled capture job is
submitted.
This page has the following elements:
The Summary section gives you important information regarding the current workload capture.
Use the Stop Capture button while capture is in progress.
The Workload Profile subpage provides several performance-related totals for the capture. Click
View Workload Capture Report to invoke a browser window to display the report. The report
contains detailed information about the capture. The Comparison table compares the entire
system with what has been captured. The Total column shows cumulative values for the system
after you started the capture, and the Capture column shows the portion of these values that the
capture yielded during the same period of time.
The Workload Filters subpage shows the workload filters that you set up in the Options step of
the Capture Workload Wizard.
When your workload is finished, click Stop Capture.

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


Using the Capture Wizard

5 - 24 Copyright 2007, Oracle. All rights reserved.

Using the Capture Wizard (continued)


When you confirm that you want to stop your workload capture, you are asked whether you want to
export AWR data. If you accept, the wizard generates an export job and automatically generates a
dump file that contains AWR data for the capture period. This dump file is generated in the capture
directory that you previously used to generate workload capture files.
If you choose not to export AWR data or if the job is not yet done, the Export AWR Data button
becomes available. When you click this button, a confirmation page is displayed. After confirmation,
the export runs in the background and you return to the View Workload Capture page.

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


Viewing Workload Capture History

5 - 25 Copyright 2007, Oracle. All rights reserved.

Viewing Workload Capture History


Use the View Workload Capture History page to:
Obtain an overview of all completed workload capture jobs ever performed on this database,
except for capture jobs that have been deleted
Delete one or more entries from the list of completed workload capture jobs
Access more detailed information about a workload capture job by selecting the capture name
and clicking View (or clicking the Capture Name link)
Export AWR data
A green check mark appears for a capture name in the AWR Data Exported column if AWR
data has already been exported. Otherwise, the column has an X. To export data for a capture
name with an X, select the name and click Export AWR Data. When the export is finished, a
check mark appears in the column.

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


Processing Captured Workload

5 - 26 Copyright 2007, Oracle. All rights reserved.

Processing Captured Workload


Use the Preprocess Captured Workload page to:
Select a directory object that contains a captured workload
View historical information about the completed capture before you begin to preprocess the
workload. This page contains the Capture Summary and Capture Details sections. The Workload
Profile and Workload Filters subpages are accessed in the Capture Details section.
When you have selected your directory and reviewed the capture details, click Preprocess Workload
to invoke the Preprocess Captured Workload Wizard.
RAC Note: In a RAC setup, one database instance of the preprocessing system is selected for
processing the workload recording. If recorded data was written to a local file system for nodes in the
RAC, the recorded data files from all the nodes in the RAC should first be copied to the directory for
the instance on which the preprocessing is to be done. If the captured data is stored in a shared file
system, copying is not necessary.

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


Using the Preprocess Captured Workload Wizard

5 - 27 Copyright 2007, Oracle. All rights reserved.

Using the Preprocess Captured Workload Wizard


The slide describe the preprocess flow:
Database Version: This step reminds you that the current database version must be the same as
the database where you want to replay the captured workload. If the database versions are not
the same, you can continue to the next step but the preprocessed workload may not replay
correctly on a later major version of the database.
Schedule: This page is a typical Enterprise Manager schedule page on which you must specify a
job name, credentials, and a start time.
Review: On this page, review the information you provided and click Submit to trigger the
preprocessing job. This takes you back to the Database Replay home page, where you can see a
Confirmation message pointing to the generated job.

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


Using the Replay Workload Wizard

5 - 28 Copyright 2007, Oracle. All rights reserved.

Using the Replay Workload Wizard


You are now again on the Database Replay home page. Click the Replay Workload icon to access the
Replay Workload page, where you can:
Specify the directory object that contains the preprocessed workload
View capture information about the preprocessed workload
View the replay history, if any, of the preprocessed workload
This page contains the Capture Summary and Capture Details sections. The Workload Profile and
Workload Filters subpages are accessed in the Capture Details section.
When ready, click Set Up Replay.

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


Using the Replay Workload Wizard

5 - 29 Copyright 2007, Oracle. All rights reserved.

Using the Replay Workload Wizard (continued)


Before entering the replay phase, the following items should be completed:
Restore Database: Restore the replay database to match the capture database at the start of the
workload capture. A successful workload replay depends on the application transactions
accessing the application data identical to that on the capture system. Common ways to restore
application data state include point-in-time recovery, flashback, and import/export.
Perform System Changes: You should make any desired changes to the replay system,
including any database or system upgrade, prior to replay. The primary purpose of Database
Replay is to test the effect of system changes on a real captured application workload.
Therefore, the changes you make, combined with the captured workload, define the test you are
conducting.
Resolve References to External Systems: A captured workload may contain references to
external systems that may be meaningful only in the capture environment. For example,
database links in a captured production environment may reference external production
databases that should not be referenced during replay. In such a case, you should modify any
external references that could jeopardize the production environment during replay. The Replay
Workload: References to External Systems page helps you resolve these issues.
Set Up Replay Clients: The replay client is a multithreaded program (an executable named
wrc) where each thread submits a captured sessions workload. This program is made available
as part of the standard Oracle Client as well as the Oracle Instant Client. You should install one
or more replay clients, preferably on systems other than the database host. In addition, each
replay client must be able to access the directory that holds the preprocessed workload.
Oracle Database 11g: New Features for Administrators 5 - 29
Using the Replay Workload Wizard

5 - 30 Copyright 2007, Oracle. All rights reserved.

Using the Replay Workload Wizard (continued)


On the Replay Workload: Choose Initial Options page, accept the default Replay Name, or provide
your own. You can either select the default replay or use replay options from a previous replay.
Initial replay options refer to the connection mappings and parameters on the Customize Options
page. Connections are captured along with the workload.
On the Replay Workload: Customize Options page, you can use the Connection Mappings sub-
page to conveniently use a single descriptor for all connections, either as a prepopulated string or as
an alias name that maps to the descriptor string. You can also select a separate connect descriptor
option that enables you to specify a unique descriptor for each connection. If you selected the Use
replay options from a previous replay option in the Choose Initial Options step, the Use a separate
connect descriptor option is selected and the previous replay system values appear in the table.
RAC Note: The remapping of external interactions should include the remapping of instances. In
particular, every captured connection string probably needs to be remapped to a connection string in
the replay system. If the capture system is a single instance database and the replay system is also a
single instance database, the remapping of the connection string is straightforward and involves
adding the appropriate entry to the configuration file. The same is valid when both the capture and
the replay systems are RAC databases with the same number of nodes. Remapping becomes more
complicated if the capture and replay systems have different numbers of nodes.

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


Using the Replay Workload Wizard

5 - 31 Copyright 2007, Oracle. All rights reserved.

Using the Replay Workload Wizard (continued)


The Replay Parameters subpage provides advanced parameters that control some aspects of the
replay. You saw those parameters on the Replay Options slide in this lesson.

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


Using the Replay Workload Wizard

5 - 32 Copyright 2007, Oracle. All rights reserved.

Using the Replay Workload Wizard (continued)


Workload is replayed using replay clients connected to the database. When you reach the Replay
Workload: Prepare Replay Clients page, you should be ready to start the replay clients.
Click Next. This takes you to the Replay Workload: Wait for Client Connections page. The text
below the clock changes if a replay client is connected. The Client Connections table is populated
when at least one replay client is connected.

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


Using the Replay Workload Wizard

$ wrc REPLAYDIR=/home/oracle/solutions/dbreplay USERID=system PASSWORD=oracle


Workload Replay Client: Release 11.1.0.6.0 - Production on Tue
$ wrc REPLAYDIR=/home/oracle/solutions/dbreplay USERID=system PASSWORD=oracle
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Workload Replay Client: Release 11.1.0.6.0 - Production on Tue
Wait for the replay to start (21:47:01)
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Wait for the replay to start (21:47:01)

5 - 33 Copyright 2007, Oracle. All rights reserved.

Using the Replay Workload Wizard (continued)


The Replay Workload Wizard waits for you to start the replay clients. You open separate terminal
windows to start the replay clients by using the wrc executable.
You can start multiple replay clients depending on the workload replay size. Each of the clients
initiates one or more replay threads with the database, with each replay thread corresponding to a
stream from the workload capture.
Here is a brief description of the syntax used by wrc. The userid and password parameters are
the user ID and password of the replay user for the client. The server parameter is a connection
string that connects to the instance of the replay system. The replaydir parameter points to the
directory that contains the processed replay files. The workdir parameter defines the clients
working directory; if left unspecified, it defaults to the current directory.
Check the following before starting the replay clients:
The replay client software is installed on the hosts.
The client has access to the replay directory.
The replay directory has the replay files that have been preprocessed.
The userid and password for the replay user are correct. Furthermore, the user should be
able to use the workload replay package and should have the user SWITCH privilege.
The Client Connections table is populated when at least one replay client is connected.
After you start replay clients, click Next on the Wait for Client Connections page.
Note: By default, replay is the wrc mode.
Oracle Database 11g: New Features for Administrators 5 - 33
Using the Replay Workload Wizard

$ wrc REPLAYDIR=/home/oracle/solutions/dbreplay USERID=system PASSWORD=oracle


Workload Replay Client: Release 11.1.0.6.0 - Production on Tue
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Wait for the replay to start (21:47:01)
Replay started (21:48:14)

5 - 34 Copyright 2007, Oracle. All rights reserved.

Using the Replay Workload Wizard (continued)


At this point, replay clients are waiting for the database to start the replay.
On the Replay Workload: Review page, click Submit to enter replay PREPARE mode. The replay
clients now start replaying the captured workload.

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


Viewing Workload Replay Statistics

5 - 35 Copyright 2007, Oracle. All rights reserved.

Viewing Workload Replay Statistics


A progress window provides comparison statistics as the replay progresses.
You can terminate the replay at any stage with the Stop Replay button.

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


Viewing Workload Replay Statistics

$ wrc REPLAYDIR=/home/oracle/solutions/dbreplay USERID=system PASSWORD=oracle


Workload Replay Client: Release 11.1.0.6.0 - Production on Tue
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Wait for the replay to start (21:47:01)
Replay started (21:48:14)
Replay finished (21:51:21)
$

5 - 36 Copyright 2007, Oracle. All rights reserved.

Viewing Workload Replay Statistics (continued)


On successful completion of the replay, the terminal window that started the replay clients displays
the message Replay finished, followed by a timestamp. The replayed workload is now complete.
The Elapsed Time Comparison chart shows how much time the replayed workload has taken to
accomplish the same amount of work as the captured workload.
The divergence table gives information about both the data and error discrepancies between the
replay and capture environments, which can be used as a measure of the replay quality.
RAC Note: If a specific captured instance is mapped to a new instance in the replay system, all the
captured calls for the captured instances are sent to the new instance. If the replay system is also
RAC and a captured instance is mapped to the run-time load balancing of the replay system, all
captured calls for that recorded instance are dynamically distributed to instances in the replay RAC
system using run-time load balancing.

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


Viewing Workload Replay Statistics

5 - 37 Copyright 2007, Oracle. All rights reserved.

Viewing Workload Replay Statistics (continued)


You can click the View Workload Replay Report button (or Report tab after replay has completed) to
see a browser window that displays a report containing detailed information about the replay.
The Report subpage contains several workload performance reports:
Workload Replay Report
AWR Compare Period Report
AWR Report
ASH Report

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


Packages and Procedures

DBMS_WORKLOAD_CAPTURE DBMS_WORKLOAD_REPLAY
START_CAPTURE PROCESS_CAPTURE
FINISH_CAPTURE INITIALIZE_REPLAY
ADD_FILTER PREPARE_REPLAY
DELETE_FILTER START_REPLAY
DELETE_CAPTURE_INFO CANCEL_REPLAY
GET_CAPTURE_INFO() DELETE_REPLAY_INFO
EXPORT_AWR REMAP_CONNECTION
IMPORT_AWR() EXPORT_AWR
REPORT() IMPORT_AWR
GET_REPLAY_INFO
REPORT

5 - 38 Copyright 2007, Oracle. All rights reserved.

Packages and Procedures


You need the EXECUTE privilege on the capture and replay packages to execute these packages.
These privileges are usually assigned by the DBA.
Note: For further details about the DBMS_WORKLOAD packages, see the Oracle Database PL/SQL
Packages and Types Reference 11g, Release 1.

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


Data Dictionary Views: Database Replay

DBA_WORKLOAD_CAPTURES: Lists all the workload


captures performed in the database
DBA_WORKLOAD_FILTERS: Lists all the workload filters
defined in the database
DBA_WORKLOAD_REPLAYS: Lists all the workload
replays that have been performed in the database
DBA_WORKLOAD_REPLAY_DIVERGENCE: Is used to
monitor workload divergence
DBA_WORKLOAD_CONNECTION_MAP: Is used to review all
connection strings that are used by workload replays
V$WORKLOAD_REPLAY_THREAD: Monitors the status of
external replay clients

5 - 39 Copyright 2007, Oracle. All rights reserved.

Data Dictionary Views: Database Replay


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

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


Database Replay: PL/SQL Example

exec DBMS_WORKLOAD_CAPTURE.ADD_FILTER(fname => 'sessfilt',-


fattribute => USER ,-
fvalue => 'JFV');

exec DBMS_WORKLOAD_CAPTURE.START_CAPTURE(name => 'june_peak',-


dir => 'jun07');

Execute your workload


exec DBMS_WORKLOAD_CAPTURE.FINISH_CAPTURE();

exec DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE(capture_dir => 'jun07');

wrc userid=system password=oracle replaydir=/dbreplay

exec DBMS_WORKLOAD_REPLAY.INITIALIZE_REPLAY(replay_name => 'j_r' ,-


replay_dir => 'jun07');

5 - 40 Copyright 2007, Oracle. All rights reserved.

Database Replay: PL/SQL Example


In this example, the ADD_FILTER procedure adds a filter named sessfilt that will filter out all
sessions belonging to the user name JFV.
To start the workload capture, use the START_CAPTURE procedure. In this example, a capture
named june_peak is captured and stored in a directory named jun07. Because the duration
parameter is not specified, the workload capture continues until the FINISH_CAPTURE procedure
is called. At this point, you can run your workload.
To stop the workload capture, use the FINISH_CAPTURE procedure. This procedure finalizes the
workload capture and returns the database to a normal state.
You can now generate a capture report by using the REPORT function.
To preprocess a captured workload, use the PROCESS_CAPTURE procedure. In this example, the
captured workload stored in the jun07 directory is preprocessed.
When finished, you can start your replay clients.
To initialize replay data, use the INITIALIZE_REPLAY procedure. Initializing replay data loads
the necessary metadata into tables required by the workload replay. For example, captured
connection strings are loaded into a table where they can be remapped for replay. In this example, the
INITIALIZE_REPLAY procedure loads preprocessed workload data from the jun07 directory
into the database.

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


Database Replay: PL/SQL Example

exec DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION(connection_id => 101,-


replay_connection => 'edlin44:3434/bjava21');

exec DBMS_WORKLOAD_REPLAY.PREPARE_REPLAY(synchronization => TRUE,-


think_time_scale=> 2);

exec DBMS_WORKLOAD_REPLAY.START_REPLAY ();

DECLARE
cap_id NUMBER;
rep_id NUMBER;
rep_rpt CLOB;
BEGIN
cap_id := DBMS_WORKLOAD_REPLAY.GET_REPLAY_INFO(dir => 'jun07');
/* Get the latest replay for that capture */
SELECT max(id) INTO rep_id
FROM dba_workload_replays
WHERE capture_id = cap_id;
rep_rpt := DBMS_WORKLOAD_REPLAY.REPORT(replay_id => rep_id,
format => DBMS_WORKLOAD_REPLAY.TYPE_TEXT);
END;

5 - 41 Copyright 2007, Oracle. All rights reserved.

Database Replay: PL/SQL Example (continued)


To remap connections, use the REMAP_CONNECTION procedure. In this example, the connection
that corresponds to the connection ID 101 will use the new connection string defined by the
replay_connection parameter.
To prepare workload replay on the replay system, use the PREPARE_REPLAY procedure. In this
example, the PREPARE_REPLAY procedure prepares the j_r replay to preserve the COMMIT order
in the workload capture.
To start a workload replay, use the START_REPLAY procedure. To stop a workload replay, use the
REPLAY_CANCEL procedure
To generate a workload replay report, use the REPORT function as shown in the slide.

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


Calibrating Replay Clients

$ wrc system/oracle@orcl mode=calibrate replaydir=/dbreplay


Workload Replay Client: Release 11.1.0.5.0 - Beta on Tue
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Report for Workload in: /dbreplay
-----------------------
Recommendation:
Consider using at least 1 clients divided among 1 CPU(s).
Workload Characteristics:
- max concurrency: 4 sessions
- total number of sessions: 11
Assumptions:
- 1 client process per 50 concurrent sessions
- 4 client process per CPU
- think time scale = 100
- connect time scale = 100
- synchronization = TRUE
$

5 - 42 Copyright 2007, Oracle. All rights reserved.

Calibrating Replay Clients


Because one replay client can initiate multiple sessions with the database, it is not necessary to start a
replay client for each session that was captured. The number of replay clients that need to be started
depends on the number of workload streams, the number of hosts, and the number of replay clients
for each host.
For example, suppose that a workload capture has 1,000 streams, that the number of average active
sessions from the workload capture is about 60, and that one host can drive only 50 concurrent
connections to the database. You should use two hosts, each with a replay client.
To estimate the number of replay clients and hosts that are required to replay a particular workload,
run the wrc executable in calibrate mode. In calibration mode, the wrc executable accepts the
following parameters:
replaydir specifies the directory that contains the preprocessed workload capture that you
want to replay. If unspecified, it defaults to the current directory.
process_per_cpu specifies the maximum number of client processes that can run for each
CPU. The default value is 4.
threads_per_process specifies the maximum number of threads that can run in a client
process. The default value is 50.
The example in the slide shows how to run the wrc executable in the calibrate mode. In this
example, the wrc executable is executed to estimate the number of replay clients and hosts that are
required to replay the workload capture stored in the directory named replay.
Note: To list the hosts that participated in the capture, use the list_hosts mode.
Oracle Database 11g: New Features for Administrators 5 - 42
Summary

In this lesson, you should have learned how to:


Identify the benefits of using Database Replay
List the steps involved in Database Replay
Use Enterprise Manager to record and replay
workloads

5 - 43 Copyright 2007, Oracle. All rights reserved.

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


Practice 5: Overview

This practice covers using Database Replay with


Enterprise Manager in the following scenarios:
Replaying in synchronous mode without changes
Replaying in synchronous mode after changes are
applied
Replaying in nonsynchronous mode without changes

5 - 44 Copyright 2007, Oracle. All rights reserved.

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


Automatic SQL Tuning

Copyright 2007, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to:


Set up and modify Automatic SQL Tuning
Use the PL/SQL interface to perform fine tuning
View and interpret reports generated by Automatic SQL
Tuning

6-2 Copyright 2007, Oracle. All rights reserved.

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


SQL Tuning in Oracle Database 10g

Workload

Accept profiles
SQL Tuning
Automatic High load Advisor 4
Generate
SQL profiles
2

ADDM
DBA
3
Run SQL Tuning Advisor

6-3 Copyright 2007, Oracle. All rights reserved.

SQL Tuning in Oracle Database 10g


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

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


Automatic SQL Tuning in Oracle Database 11g

AWR

To
p
SQ
L
Workload Auto matic

SQL Tuning

R
ep
o
4

rt
s DBA

6-4 Copyright 2007, Oracle. All rights reserved.

Automatic SQL Tuning in Oracle Database 11g


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

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


Summary of Automation
in Oracle Database 11g

Task runs automatically (AUTOTASK framework)


Workload automatically chosen (no SQL Tuning Set)
SQL profiles automatically tested
SQL profiles automatically implemented
SQLs automatically retuned if they regress
Reporting available over any time period

6-5 Copyright 2007, Oracle. All rights reserved.

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


Selecting Potential SQL Statements for Tuning

AWR
Weekly Daily Hourly Avrg execution

Candidate list

1. Pull the top queries from the past week into four buckets:
y Top for the past week
y Top for any day in the past week
y Top in any single snapshot
y Top by average single execution
2. Combine four buckets into one (assigning weights).
3. Cap at 150 queries per bucket.

6-6 Copyright 2007, Oracle. All rights reserved.

Selecting Potential SQL Statements for Tuning


Oracle Database 11g analyzes the statistics in the AWR and generates a list of potential SQL
statements that are eligible for tuning. These statements include repeating high-load statements that
have a significant impact on the system. Only SQL statements that have an execution plan with a
high potential for improvement will be tuned. Recursive SQL and statements that have been tuned
recently (in the last month) are ignored, as are parallel queries, DMLs, DDLs, and SQL statements
with performance problems that are caused by concurrency issues.
The SQL statements that are selected as candidates are then ordered based on their performance
impact. The performance impact of a SQL statement is calculated by summing the CPU time and the
I/O times captured in the AWR for that SQL statement in the past week.

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


Maintenance Window Timeline

Automatic SQL Tuning task

Pick
Tune Test Accept Tune
candidate
S1 P1 P1 S2
SQL

One hour maximum (by default)

Maintenance
window

6-7 Copyright 2007, Oracle. All rights reserved.

Maintenance Window Timeline


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

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


Automatic Tuning Process
Not considered

Restructure
SQL New
SQL profile

Existing N 3X Y
benefit? Accept profile
Indexes profile?

N
Y

3X N
Ignore new profile
benefit?
Stale
stats
Y

Replace profile

GATHER_STATS_JOB

6-8 Copyright 2007, Oracle. All rights reserved.

Automatic Tuning Process


With the list of candidate SQL already built and ordered, the statements are then tuned using SQL
Tuning Advisor. During the tuning process, all the recommendation types are considered and
reported, but only SQL profiles can be implemented automatically (when the
ACCEPT_SQL_PROFILES task parameter is set to TRUE). Otherwise, only the recommendation to
create a SQL profile will be reported in the automatic SQL tuning reports.
In Oracle Database 11g, the performance improvement factor has to be at least three before a SQL
profile is implemented. As we have already mentioned, the Automatic SQL Tuning process
implements only SQL profile recommendations automatically. Other recommendations (to create
new indexes, refresh stale statistics, or restructure SQL statements) are generated as part of the SQL
tuning process but are not implemented. These are left for the DBA to review and implement
manually, as appropriate.
Here is a short description of the general tuning process:
Tuning is performed on a per-statement basis. Because only SQL profiles can be implemented, there
is no need to consider the effect of such recommendations on the workload as a whole. For each
statement (in order of importance), the tuning process carries out each of the following steps:
1. Tune the statement by using SQL Tuning Advisor. Look for a SQL profile and, if it is found,
verify that the base optimizer statistics are current for it.

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


Automatic Tuning Process (continued)
2. If a SQL profile is recommended, perform the following:
- Test the new SQL profile by executing the statement with and without it.
- When a SQL profile is generated and it causes the optimizer to pick a different execution
plan for the statement, the advisor must decide whether to implement the SQL profile. It
makes its decision according to the flowchart in the slide. Although the benefit thresholds
here apply to the sum of CPU and I/O time, SQL profiles are not accepted when there is
degradation in either statistic. So the requirement is that there is a three-times improvement
in the sum of CPU and I/O time, with neither statistic becoming worse. In this way, the
statement runs faster than it would without the profile, even with contention in CPU or I/O.
3. If stale or missing statistics are found, make this information available to
GATHER_STATS_JOB.
Automatic implementation of tuning recommendations is limited to SQL profiles because they have
fewer risks. It is easy for a DBA to revert the implementation.
Note: All SQL profiles are created in the standard EXACT mode. They are matched and tracked
according to the current value of the CURSOR_SHARING parameter. DBAs are responsible for
setting CURSOR_SHARING appropriately for their workload.

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


DBA Controls

Autotask configuration:
On/off switch
Maintenance windows running tuning task
CPU resource consumption of tuning task
Task parameters:
SQL profile implementation automatic/manual switch
Global time limit for tuning task
Per-SQL time limit for tuning task
Test-execute mode disabled to save time
Maximum number of SQL profiles automatically
implemented per execution as well as overall
Task execution expiration period

6 - 10 Copyright 2007, Oracle. All rights reserved.

DBA Controls
Here is a PL/SQL control example for the Automatic SQL Tuning task:
BEGIN
dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQL_TUNING_TASK',
'LOCAL_TIME_LIMIT', 1400);
dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQL_TUNING_TASK',
'ACCEPT_SQL_PROFILES', 'TRUE');
dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQL_TUNING_TASK',
'MAX_SQL_PROFILES_PER_EXEC', 50);
dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQL_TUNING_TASK',
'MAX_AUTO_SQL_PROFILES', 10002);
END;
The last three parameters in this example are supported only for the Automatic SQL Tuning task.
You can also use parameters such as LOCAL_TIME_LIMIT, or TIME_LIMIT, which are valid
parameters for the traditional SQL tuning tasks. One important example is to disable test-execute
mode (to save time) and to use only execution plan costs to decide about the performance by using
the TEST_EXECUTE parameter.
In addition, you can control when the Automatic SQL Tuning task runs and the CPU resources that it
is allowed to use.

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


Automatic SQL Tuning Task

6 - 11 Copyright 2007, Oracle. All rights reserved.

Automatic SQL Tuning Task


As has already been mentioned, Automatic SQL Tuning is implemented as an automated
maintenance task that is itself called Automatic SQL Tuning. You can see some high-level
information about the last runs of the Automatic SQL Tuning task by going to the Automated
Maintenance Tasks page: On your Database Control home page, click the Server tab and, when you
are on the Server page, click the Automated Maintenance Tasks link in the Tasks section.
On the Automated Maintenance Tasks page, you see the predefined tasks. You then access each task
by clicking the corresponding link to get more information about the task itself (illustrated in the
slide). When you click either the Automatic SQL Tuning link or the latest execution icon (the green
area on the timeline), you go to the Automatic SQL Tuning Result Summary page.

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


Configuring Automatic SQL Tuning

6 - 12 Copyright 2007, Oracle. All rights reserved.

Configuring Automatic SQL Tuning


You can configure various Automatic SQL Tuning parameters by using the Automatic SQL Tuning
Settings page.
To get to that page, click the Configure button on the Automated Maintenance Tasks page. This takes
you to the Automated Maintenance Tasks Configuration page, where you can see the various
maintenance windows that are delivered with Oracle Database 11g.
By default, Automatic SQL Tuning executes on all predefined maintenance windows in the
MAINTENANCE_WINDOW_GROUP. You can disable it for specific days in the week. On this page,
you can also edit each Window to change its characteristics. You can do so by clicking Edit Window
Group.
To get to the Automatic SQL Tuning Settings page, click the Configure button on the line
corresponding to Automatic SQL Tuning in the Task Settings section.
On the Automatic SQL Tuning Settings page, you can specify the parameters shown in the slide. By
default, Automatic Implementation of SQL Profiles is deactivated.
Note: If you set STATISTICS_LEVEL to BASIC, turn off the AWR snapshots by using
DBMS_WORKLOAD_REPOSITORY, or if AWR retention is less than seven days, you also stop
Automatic SQL Tuning.

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


Automatic SQL Tuning Result Summary

6 - 13 Copyright 2007, Oracle. All rights reserved.

Automatic SQL Tuning Result Summary


In addition, the Automatic SQL Tuning Result Summary page contains various summary graphs so
that you can control the Automatic SQL Tuning task. An example is given in the slide. The first chart
in the Overall Task Statistics section shows you the breakdown by finding types for the designated
period of time. You can control the period of time for which you want the report to be generated by
selecting a value from the Time Period list. In the example, Customized is used; it shows you the
latest run. You can choose All to cover all executions of the task so far. Users can request it for any
time period over the past month, since that is the amount of time for which the advisor persists its
tuning history. You then generate the report by clicking View Report.
On the Breakdown by Finding Type chart, you can clearly see that only SQL profiles can be
implemented. Although many more profiles were recommended, not all of them were automatically
implemented for the reasons that we already explained. Similarly, recommendations for index
creation and other types are not implemented. However, the advisor keeps historical information
about all the recommendations if you want to implement them later.
In the Profile Effect Statistics section, you can see the Tuned SQL DB Time Benefit chart, which
shows you the before-and-after DB Time for implemented profiles and other recommendations.

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


Automatic SQL Tuning: Result Details

6 - 14 Copyright 2007, Oracle. All rights reserved.

Automatic SQL Tuning: Result Details


On the Automatic SQL Tuning Result Details page, you can also see a variety of important
information for each automatically tuned SQL statement, including its SQL text and SQL ID, the
type of recommendation that was done by SQL Tuning Advisor, the verified benefit percentage,
whether a particular recommendation was automatically implemented, and the date of the
recommendation.
From this page, you can either drill down to the SQL statement itself by clicking its corresponding
SQL ID link, or you can select one of the SQL statements and click the View Recommendations
button to have more details about the recommendation for that statement.
Note: The benefit percentage shown for each recommendation is calculated using the formula
bnf% = (time_old - time_new)/(time_old). With this formula, you can see that a three-
time benefit (for example, time_old = 100, time_new = 33) corresponds to 66%. So the system
implements any profiles with benefits over 66%. According to this formula, 98% is a 50 times
benefit.

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


Automatic SQL Tuning Result Details: Drilldown

6 - 15 Copyright 2007, Oracle. All rights reserved.

Automatic SQL Tuning Result Details: Drilldown


On the Recommendations for SQL ID page, you can see the corresponding recommendations and
implement them manually.
By clicking the SQL Test link, you access the SQL Details page, where you see the tuning history as
well as the plan control associated with your SQL statement.
In the slide, you see that the statement was tuned by Automatic SQL Tuning and that the associated
profile was automatically implemented.

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


Automatic SQL Tuning: Fine Tune

Use DBMS_SQLTUNE:
SET_TUNING_TASK_PARAMETER
EXECUTE_TUNING_TASK
REPORT_AUTO_TUNING_TASK
Use DBMS_AUTO_TASK_ADMIN:
ENABLE
DISABLE
Dictionary views:
DBA_ADVISOR_EXECUTIONS
DBA_ADVISOR_SQLSTATS
DBA_ADVISOR_SQLPLANS

6 - 16 Copyright 2007, Oracle. All rights reserved.

Automatic SQL Tuning: Fine Tune


You can use the DBMS_SQLTUNE PL/SQL package to control various aspects of
SYS_AUTO_SQL_TUNING_TASK.
1. SET_TUNING_TASK_PARAMETERS: The following parameters are supported for the
automatic tuning task only:
ACCEPT_SQL_PROFILES: TRUE/FALSE whether the system should accept SQL profiles
automatically
REPLACE_USER_SQL_PROFILES: TRUE/FALSE whether the task should replace SQL
profiles created by the user
MAX_SQL_PROFILES_PER_EXEC: Maximum number of SQL profiles to create for each
run
MAX_AUTO_SQL_PROFILES: Maximum number of automatic SQL profiles allowed on
the system in total
EXECUTION_DAYS_TO_EXPIRE: Specifies the number of days to save the task history
in the advisor framework schema. By default, the task history is saved for 30 days before it
expires.
2. EXECUTE_TUNING_TASK function: Used to manually run a new execution of the task in the
foreground (behaves in the same way that it runs in the background)
3. REPORT_AUTO_TUNING_TASK: Get a text report covering a range of task executions
You can enable and disable SYS_AUTO_SQL_TUNING_TASK by using the
DBMS_AUTO_TASK_ADMIN PL/SQL package.
Oracle Database 11g: New Features for Administrators 6 - 16
Automatic SQL Tuning: Fine Tune (continued)
You can also access Automatic SQL Tuning information through the dictionary views listed in the
slide:
DBA_ADVISOR_EXECUTIONS: Get data about each execution of the task
DBA_ADVISOR_SQLSTATS: See the test-execute statistics generated while testing the SQL
profiles
DBA_ADVISOR_SQLPLANS: See the plans encountered during test-execute

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


Using the PL/SQL Interface to Generate Reports
SQL> variable my_rept CLOB;
SQL> BEGIN
2 :my_rept :=DBMS_SQLTUNE.REPORT_AUTO_TUNING_TASK(begin_exec=>NULL,
3 end_exec=>NULL, type=>'TEXT', level=>'TYPICAL', section=>'ALL',
4 object_id=>NULL, result_limit=>NULL);
END;
/

SQL> print :my_rept

MY_REPT
--------------------------------------------------------------------------------
GENERAL INFORMATION SECTION
Tuning Task Name : SYS_AUTO_SQL_TUNING_TASK
Tuning Task Owner : SYS
Workload Type : Automatic High-Load SQL Workload
Scope : COMPREHENSIVE
Global Time Limit(seconds) : 3600
Per-SQL Time Limit(seconds) : 1200

Number of SQLs with Statistic Findings : 1
Number of SQLs with SQL profiles recommended : 2
Number of SQLs with SQL profiles implemented : 2
Number of SQLs with Index Findings : 1
Number of SQLs with Errors : 1

6 - 18 Copyright 2007, Oracle. All rights reserved.

Using the PL/SQL Interface to Generate Reports


The example in the slide shows how to generate a text report to display all SQL statements that were
analyzed in the most recent execution, including recommendations that were not implemented. All
sections of the report are included.
Depending on the sections that were included in the report, you can view information about the
automatic SQL tuning task in the following sections of the report:
The general information section provides a high-level description of the automatic SQL tuning
task, including information about the inputs given for the report, the number of SQL statements
tuned during the maintenance, and the number of SQL profiles that were created.
The summary section lists the SQL statements (by their SQL identifiers) that were tuned during
the maintenance window and the estimated benefit of each SQL profile, or their actual execution
statistics after test-executing the SQL statement with the SQL profile.
The Tuning findings section gives you all findings and statistics that are associated with each
SQL statement, as well as whether profiles were accepted (and why).
The Explain plans section shows the old and new explain plans used by each SQL statement
analyzed by SQL Tuning Advisor.
The Errors section lists all errors encountered by the Automatic SQL Tuning task.
Note: Obtain the execution list by using the following command:
select execution_name,status,execution_start,execution_end
from dba_advisor_executions
where task_name='SYS_AUTO_SQL_TUNING_TASK';
Oracle Database 11g: New Features for Administrators 6 - 18
Automatic SQL Tuning Considerations

SQL not considered for Automatic SQL Tuning:


Ad hoc or rarely repeated SQL
Parallel queries
Long-running queries after profiling
Recursive SQL statements
DML and DDL
These statements can still be manually tuned by using
SQL Tuning Advisor.

6 - 19 Copyright 2007, Oracle. All rights reserved.

Automatic SQL Tuning Considerations


Automatic SQL Tuning does not seek to solve every SQL performance issue occurring on a system.
It does not consider the following types of SQL.
Ad hoc or rarely repeated SQL: If a SQL is not executed multiple times in the same form, the
advisor ignores it. SQL that do not repeat within a week are also not considered.
Parallel queries.
Long-running queries (post-profile): If a query takes too long to run after being SQL profiled, it
is not practical to test-execute and, therefore, it is ignored by the advisor. Note that this does not
mean that the advisor ignores all long-running queries. If the advisor can find a SQL profile that
causes a query that once took hours to run in minutes, it could be accepted because test-
execution is still possible. The advisor would execute the old plan just long enough to determine
that it is worse than the new one, and then would terminate test-execution without waiting for
the old plan to finish, thereby switching the order of execution.
Recursive SQL statements
DMLs such as INSERT SELECT or CREATE TABLE AS SELECT
With the exception of truly ad hoc SQL, these limitations apply to Automatic SQL Tuning only.
Such statements can still be tuned by manually running SQL Tuning Advisor.

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


Summary

In this lesson, you should have learned how to:


Set up and modify Automatic SQL Tuning
Use the PL/SQL interface to perform fine tuning
View and interpret reports generated by Automatic
SQL Tuning

6 - 20 Copyright 2007, Oracle. All rights reserved.

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


Practice 6: Overview

This practice covers using Automatic SQL Tuning.

6 - 21 Copyright 2007, Oracle. All rights reserved.

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


Intelligent Infrastructure
Enhancements

Copyright 2007, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to:


Create AWR baselines for future time periods
Identify the views that capture foreground statistics
Control automated maintenance tasks
Use Resource Manager I/O calibration
Use lightweight jobs with the Scheduler

7-2 Copyright 2007, Oracle. All rights reserved.

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


AWR Baselines

7-3 Copyright 2007, Oracle. All rights reserved.

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


Comparative Performance Analysis
with AWR Baselines
Performance
AWR Baseline contains a set of AWR
snapshots for an interesting or
Actual
reference period of time
Baseline is key for performance
tuning to:
Guide setting of alert thresholds
Monitor performance
Compare advisor reports
Normal
AWR Baseline

time

7-4 Copyright 2007, Oracle. All rights reserved.

Comparative Performance Analysis with AWR Baselines


What is the proper threshold to set on a performance metric? What is it that you want to detect? If
you want to know that the performance metric value indicates that the server is nearing capacity, an
absolute value is correct. But if you want to know that the performance is different today than it was
at this time last week, or last month, the current performance must be compared to a baseline.
A baseline is a set of snapshots taken over a period of time. These snapshots are grouped statistically
to yield a set of baseline values that vary over time. For example, the number of transactions per
second in a certain database varies depending on the time of the day. The values for transactions per
second are higher during working hours and lower during nonworking hours. The baseline records
this variation and can be set to alert you if the current number of transactions per second is
significantly different from the baseline values.
Oracle Database 11g baselines provide the data required to calculate time-varying thresholds based
on the baseline data. The baseline allows a real-time comparison of performance metrics with
baseline data and can be used to produce AWR reports that compare two periods.

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


Automatic Workload Repository Baselines

Oracle Database 11g further enhances the Automatic


Workload Repository baselines:
Out-of-the-box moving window baselines for which you
can specify adaptive thresholds
Schedule the creation of a baseline by using baseline
templates.
Rename baselines.
Set expiration dates for baselines.

7-5 Copyright 2007, Oracle. All rights reserved.

Automatic Workload Repository Baselines


Oracle Database 11g consolidates the various concepts of baselines in Oracle (specifically in
Enterprise Manager and RDBMS) into the single concept of the Automatic Workload Repository
(AWR) baseline. Oracle Database 11g AWR baselines provide powerful capabilities for defining
dynamic and future baselines, and considerably simplify the process of creating and managing
performance data for comparison purposes.
Oracle Database 11g introduces the concept of moving window baselines. By default, a system-
defined moving window baseline is created that corresponds to all the AWR data within the AWR
retention period.
Oracle Database 11g provides the ability to collect two kinds of baselines: moving window and static
baselines. Static baselines can be either single or repeating. A single AWR baseline is collected over
a single time period. A repeating baseline is collected over a repeating time period (for example,
every Monday in June).
In Oracle Database 11g, baselines are enabled by default if STATISTICS_LEVEL=TYPICAL or
ALL.

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


Moving Window Baseline

There is one moving window baseline:


SYSTEM_MOVING_WINDOW: A moving window baseline
that corresponds to the last eight days of AWR data
Created out-of-the-box in 11g
By default, the adaptive thresholds functionality computes
statistics on this baseline.

7-6 Copyright 2007, Oracle. All rights reserved.

Moving Window Baseline


Oracle Database automatically maintains a system-defined moving window baseline. The default
window size for the system-defined moving window baseline is the current AWR retention period,
which by default is eight days. If you are planning to use adaptive thresholds, consider using a larger
moving window (such as 30 days) to accurately compute threshold values. You can resize the
moving window baseline by changing the number of days in the moving window to a value that is
equal to or less than the number of days in the AWR retention period. Therefore, to increase the size
of a moving window, you first need to increase the AWR retention period accordingly.
This system-defined baseline provides a default out-of-the-box baseline for EM performance screens
to compare the performance with the current database performance.
Note: The default retention period for snapshot data has been changed from seven days to eight days
in Oracle Database 11g to ensure the capture of an entire week of performance data.

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


Baselines in Performance Page Settings

7-7 Copyright 2007, Oracle. All rights reserved.

Baselines in Performance Page Settings


The data for any defined baseline in the past is available in Oracle Database 11g. The baseline data
may be displayed on the Performance page of Enterprise Manager. You have three display options:
Do not show baseline information.
Show the information from a specified static baseline.
Show the information from the system moving baseline.
Note: The system moving window baseline becomes valid after sufficient data has been collected
and the statistics calculation occurs. By default, the statistics calculation is scheduled for every
Saturday at midnight.

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


Baseline Templates

Templates enable you to schedule the creation of


baselines for any time period(s) of interest in the
future:
Single time period in the future
Repeating schedule
Examples
A known holiday weekend
Every Monday morning from 10 AM to 2 PM
When the end time for a baseline template changes
from future to past, MMON detects the change and
creates the baseline.

7-8 Copyright 2007, Oracle. All rights reserved.

Baseline Templates
Creating baselines for future time periods allows you to mark time periods that you know will be
interesting. For example, you may want the system to automatically generate a baseline for every
Monday morning for the whole year, or you can ask the system to generate a baseline for an
upcoming holiday weekend if you suspect that it is a high-volume weekend.
Previously, you could create baselines only on snapshots that already existed. With Oracle Database
11g, a nightly MMON task goes through all the templates for baseline generation and checks to see if
any time ranges have changed from the future to the past within the last day. For the relevant time
periods, the MMON task then creates a baseline for the time period.

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


Creating AWR Baselines

7-9 Copyright 2007, Oracle. All rights reserved.

Creating AWR Baselines


You can create two types of AWR baselines: single and repeating. The Create Baseline: Baseline
Interval Type page gives the following explanations.
The single type of baseline has a single and fixed time interval: for example, from Jan 1, 2007, at
10:00 AM, to Jan 1, 2007, at 12:00 PM. The repeating type of baseline has a time interval that
repeats over a time period: for example, every Monday from 10:00 AM to 12:00 PM for the year
2007.
To view the AWR Baseline page, click the AWR Baselines link on the Server tab of the Database
Instance page. On the Baseline page, click Create and follow the wizard to create your baseline.
Note: Before you can set up AWR baseline metric thresholds for a particular baseline, you must
compute the baseline statistics. Select Schedule Statistics Computation from the actions menu to
compute the baseline statistics. There are several other actions available.

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


Single AWR Baseline

OK has change to Finish in Beta 5

7 - 10 Copyright 2007, Oracle. All rights reserved.

Single AWR Baseline


If you selected the Single option in the previous step, you access the page shown in this slide.
Select the time period corresponding to your interest in one of two ways:
Select the Snapshot Range option, and then set the Period Start Time and Period End Time by
following the directions on the page. If the Icon that you want to select is not shown, you can
change the chart time period.
Specify the Time Range, with a date and time for start and end times. With Time Range, you
can choose times in the future.
When you are finished, click Finish to create the static baseline.
Note: If the End Time of the baseline is in the future, a baseline template with the same name as the
baseline will be created.

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


Creating a Repeating
Baseline Template

7 - 11 Copyright 2007, Oracle. All rights reserved.

Creating a Repeating Baseline Template


You can define repeating baselines by using Enterprise Manager. In the wizard, after selecting
Repeating in step 1, you can specify the repeat interval as shown in this slide. You specify the start
time and the duration of the baseline. Then specify when the baseline statistics will be collected
(daily or weekly; if weekly, for which days). Specify the range of dates for which this baseline
template will collect statistics. Retention Time sets an expiration value for the baseline; a value of
NULL indicates that the baseline never expires.

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


Generate a Baseline Template for
a Single Time Period
Interesting time
period

.. T4 T5 T6 .. Tx Ty Tz

BEGIN
DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE_TEMPLATE (
start_time => to_date('21-JUN-2008','DD-MON-YYYY'),
end_time => to_date('21-SEP-2008','DD-MON-YYYY'),
baseline_name => 'FALL08',
template_name => 'FALL08',
expiration => NULL ) ;
END;

7 - 12 Copyright 2007, Oracle. All rights reserved.

Generate a Baseline Template for a Single Time Period


You can now create a template for how baselines are to be created for different time periods in the
future, for predictable schedules. If any part of the period is in the future, use the
CREATE_BASELINE_TEMPLATE procedure.
For the baseline template, when the end time becomes a time in the past, a task using these inputs
automatically creates a baseline for the specified time period when the time comes. The example
creates a baseline template that creates a baseline when 0:0:0 21-Sep-2008 is in the past.
Using time-based definitions in baseline creation does not require the start-snapshot and end-
snapshot identifiers. For the CREATE_BASELINE_TEMPLATE procedure, you can also now
specify an expiration duration for the baseline that is created from the template. The expiration
duration, specified in days, represents the number of days you want the baselines to be maintained.
A value of NULL means that the baselines never expire.
To create a baseline over a period in the past, use the CREATE_BASELINE procedure (as in Oracle
Database 10g). The CREATE_BASELINE procedure has one new parameter: expiration duration.
Expiration duration has the same meaning as it does for CREATE_BASELINE_TEMPLATE.

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


Creating a Repeating
Baseline Template

BEGIN
DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE_TEMPLATE (
day_of_week => 'SATURDAY',
hour_in_day => 6,
duration => 20,
start_time => to_date('21-JUN-2007','DD-MON-YYYY'),
end_time => to_date('21-JUN-2008','DD-MON-YYYY'),
baseline_name_prefix => 'SAT_MAINT_WIN'
template_name => 'SAT_MAINT_WIN',
expiration => 90,
dbid => NULL );
END;

7 - 13 Copyright 2007, Oracle. All rights reserved.

Creating a Repeating Baseline Template


Use the CREATE_BASELINE_TEMPLATE procedure to generate baseline templates that
automatically create baselines for a contiguous time period based on a repeating time schedule.
You can also specify whether you want the baseline to be automatically removed after a specified
expiration interval (expiration).
The example in the slide generates a template that creates a baseline for a period that corresponds to
each SATURDAY_MAINTENANCE_WINDOW for a year. The baseline is created over a 20-hour
period (duration) that starts at 6:00 AM (hour_in_day) each Saturday (day_of_week). The
baseline is named SAT_MAINT_WIN with time information appended to make the name unique.
The template is named SAT_MAINT_WIN, and each baseline will be kept for 90 days
(expiration). This template is created for the local database ( dbid => NULL ).
Use this baseline to compare the resources that are used each Saturday during the maintenance
window.

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


DBMS_WORKLOAD_REPOSITORY Package

The following procedures have been added:


CREATE_BASELINE_TEMPLATE
RENAME_BASELINE
MODIFY_BASELINE_WINDOW_SIZE
DROP_BASELINE_TEMPLATE
The following function has been added:
SELECT_BASELINE_METRIC

7 - 14 Copyright 2007, Oracle. All rights reserved.

DBMS_WORKLOAD_REPOSITORY Package
The slide shows the set of PL/SQL interfaces offered by Oracle Database 11g in the
DBMS_WORKLOAD_REPOSITORY package for administration and filtering.
MODIFY_BASELINE_WINDOW_SIZE enables you to modify the size of the
SYSTEM_MOVING_WINDOW.

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


Baseline Views

Data dictionary support for baselines:


Modified DBA_HIST_BASELINE
New DBA_HIST_BASELINE_DETAILS
New DBA_HIST_BASELINE_TEMPLATE

7 - 15 Copyright 2007, Oracle. All rights reserved.

Baseline Views
The data dictionary views supporting the AWR baselines have changed.
DBA_HIST_BASELINE: Modified View
DBA_HIST_BASELINE has been modified to support the SYSTEM_MOVING_WINDOW baseline
and the baselines generated from templates. Additional information includes the date created, time of
last statistics calculation, and type of baseline.
DBA_HIST_BASELINE_DETAILS: New View
DBA_HIST_BASELINE_DETAILS displays information that allows you to determine the validity
of a given baseline, such as whether there was a shutdown during the baseline period and the
percentage of the baseline period that is covered by the snapshot data.
DBA_HIST_BASELINE_TEMPLATE: New View
DBA_HIST_BASELINE_TEMPLATE holds the baseline templates. This view provides the
information needed by MMON to determine when a baseline will be created from a template and when
the baseline should be removed.
For details, see Oracle Database Reference 11g.

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


Thresholds

7 - 16 Copyright 2007, Oracle. All rights reserved.

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


Performance Monitoring and Baselines

Performance alert thresholds are difficult to determine:


Expected metric values vary by workload type.
Expected metric values vary by system load.
Baselines can capture metric value statistics:
Automatically computed over the system moving window
Manually computed over static baselines

7 - 17 Copyright 2007, Oracle. All rights reserved.

Performance Monitoring and Baselines


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

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


Performance Monitoring and Baselines

Baseline metric statistics determine alert thresholds:


Unusual values versus baseline data =
significance level thresholds
Close or exceeding peak value over baseline data =
percentage of maximum thresholds

7 - 18 Copyright 2007, Oracle. All rights reserved.

Performance Monitoring and Baselines (continued)


Metric statistics computed over a baseline enable you to set thresholds that compare the baseline
statistics to the current activity. There are three methods of comparison: significance level,
percentage of maximum, and fixed values.
Thresholds based on significance level use statistical relevance to determine which current values are
unusual. In simple terms, if the significance level is set to .99 for a critical threshold, the threshold is
set where 1% of the baseline values fall outside this value and any current values that exceed this
value trigger an alert. A higher significance level of .999 or .9999 causes fewer alerts to be triggered.
Thresholds based on percentage of maximum are calculated based on the maximum value captured
by the baseline.
Threshold values based on fixed values are set by the DBA. No baseline is required.

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


Defining Alert Thresholds Using Static Baseline

7 - 19 Copyright 2007, Oracle. All rights reserved.

Defining Alert Thresholds Using Static Baseline


After AWR baseline statistics are computed for a particular baseline, you can set metric thresholds
specific to your baseline.
Compute baseline statistics directly from the Baselines page (as previously discussed). Then go to
the AWR Baseline Metric Thresholds page and select the type of metrics that you want to set. When
done, select a specific metric and click Edit Thresholds.
On the corresponding Edit AWR Baseline Metric Thresholds page, specify your thresholds in the
Thresholds Settings section, and then click Apply Thresholds.
You can specify thresholds based on the statistics computed for your baseline. This is illustrated in
the slide. In addition to Significance Level, the other possibilities are Percentage of Maximum
and Fixed Values.
Note: After a threshold is set using Baseline Metric Thresholds, the previous threshold values are
forgotten forever and the statistics from the associated baseline are used to determine the threshold
values until they are cleared (by using the Baseline Metric Threshold UI or PL/SQL interface).

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


Using EM to Quickly Configure
Adaptive Thresholds

7 - 20 Copyright 2007, Oracle. All rights reserved.

Using EM to Quickly Configure Adaptive Thresholds


Oracle Database 11g Enterprise Manager provides significant usability improvements in the selection
of adaptive thresholds for database performance metrics, with full integration with AWR baselines as
the source for the metric statistics. EM offers a quick configuration option in a one-click starter set of
thresholds based on OLTP or Data Warehouse workload profiles.
Make the selection of the appropriate workload profiles from the subsequent pop-up window. By
making this simple selection, the system automatically configures and evolves adaptive thresholds
based on the SYSTEM_MOVING_WINDOW baseline for the group of metrics that best correspond to
the chosen workload.

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


Using EM to Quickly Configure
Adaptive Thresholds

7 - 21 Copyright 2007, Oracle. All rights reserved.

Using EM to Quickly Configure Adaptive Thresholds (continued)


On the OLTP Threshold settings page, configure the desired workload baselines. When it is
configured, you can edit the threshold levels by using the Edit Threshold button.
The Warning Level and Critical Level columns indicate the type of alert generated. The Significance
Level indicates whether the level of observation is at or above a certain value. The following
significance level thresholds are supported:
High: Significant at 0.95 level (5 in 100)
Very High: Significant at 0.99 level (1 in 100)
Severe: Significant at 0.999 level (1 in 1,000)
Extreme: Significant at 0.9999 level (1 in 10,000)
Tip: When editing threshold levels, set the significance level thresholds conservatively and
experimentally at first, and then observe the number and significance of alerts. Higher significance
levels reduce the number of alerts.
The threshold values are determined by examining the statistics for the metric values observed over
the baseline time period. The system sets the thresholds based on prior data from the system itself
and some metadata provided by you. This is significantly easier in the multitarget case because you
no longer need to know the system-specific metric. The statistics to monitor are the maximum value
as well as the significance levels. The significance levels let you set the threshold to a value that is
statistically significant at the stated level (for example, 1 in 1,000).

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


7 - 22 Copyright 2007, Oracle. All rights reserved.

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


Practice 7-1: Overview

This practice covers creating AWR baselines:


Creating a baseline over a past time interval
Applying the baseline to the performance page graphs
Creating a repeating period baseline over periods in the
future

7 - 23 Copyright 2007, Oracle. All rights reserved.

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


Automated Maintenance Tasks

7 - 24 Copyright 2007, Oracle. All rights reserved.

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


Maintenance Windows

10 p.m. 2 a.m. Mon to Fri 6 a.m. 2 a.m. Sat to Sun

7 - 25 Copyright 2007, Oracle. All rights reserved.

Maintenance Windows
Oracle Database 10g introduced the execution of automated maintenance tasks during a maintenance
window. The automated tasks are statistics collection, segment advisor, and Automatic SQL Tuning.
With Oracle Database 11g, the Automated Maintenance Tasks feature relies on the Resource
Manager being enabled during the maintenance windows. Thus the resource plan associated with the
window is automatically enabled when the window opens. The goal is to prevent maintenance work
from consuming excessive amounts of system resources. Each maintenance window is associated
with a resource plan that specifies how the resources will be allocated during the window duration.
In Oracle Database 11g, WEEKNIGHT_WINDOW and WEEKEND_WINDOW (defined in Oracle
Database 10g) are replaced with daily maintenance windows. Automated tasks are assigned to
specific windows. All daily windows belong to MAINTENANCE_WINDOW_GROUP by default.
You are still completely free to define other maintenance windows as well as change start times and
durations for the daily maintenance windows. Likewise, any maintenance windows that are deemed
unnecessary can be disabled or removed. The operations can be done by using EM or Scheduler
interfaces.

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


Default Maintenance Plan

SQL> SELECT name FROM V$RSRC_PLAN


2 WHERE is_top_plan = 'TRUE';

NAME
--------------------------------
DEFAULT_MAINTENANCE_PLAN

7 - 26 Copyright 2007, Oracle. All rights reserved.

Default Maintenance Plan


When a maintenance window opens, the DEFAULT_MAINTENANCE_PLAN in the Resource
Manager is automatically set to control the amount of CPU used by the automated maintenance tasks.
To be able to give different priorities to each possible task during a maintenance window, various
consumer groups are assigned to DEFAULT_MAINTENANCE_PLAN. The hierarchy between groups
and plans is shown in the slide.
For high-priority tasks:
Optimizer Statistics Gathering automatic task is assigned to the
ORA$AUTOTASK_STATS_GROUP consumer group
Segment Advisor automatic task is assigned to the ORA$AUTOTASK_SPACE_GROUP
consumer group
Automatic SQL Tuning automatic task is assigned to the ORA$AUTOTASK_SQL_GROUP
consumer group
Note: If necessary, you can manually change the percentage of CPU resources allocated to the
various automated maintenance task consumer groups inside ORA$AUTOTASK_HIGH_SUB_PLAN.

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


Automated Maintenance Task Priorities

Run Job1 Run Job2 Run Job3 Run Job3 Run Job4
with with with with with
urgent urgent high medium medium
priority priority priority priority priority

urgent MMON
Stats high

Maintenance medium
window ABP

Space

Job1 Jobn
SQL

DBA_AUTOTASK_TASK

7 - 27 Copyright 2007, Oracle. All rights reserved.

Automated Maintenance Task Priorities


The Automated Maintenance Tasks feature is implemented by Autotask Background Process (ABP).
ABP functions as an intermediary between automated tasks and the Scheduler. Its main purpose is to
translate automated tasks into AUTOTASK jobs for execution by the Scheduler. Just as important,
ABP maintains a history of execution of all tasks. ABP stores its private repository in the SYSAUX
tablespace; you view the repository through DBA_AUTOTASK_TASK.
ABP is started by MMON at the start of a maintenance window. There is only one ABP required for all
instances. The MMON process monitors ABP and restarts it if necessary.
ABP determines the list of jobs that need to be created for each maintenance task. This list is ordered
by priority: urgent, high, and medium. Within each priority group, jobs are arranged in the preferred
order of execution. ABP creates jobs in the following manner: all urgent-priority jobs are created
first, all high-priority jobs are created next, and all medium-priority jobs are created last.
ABP assigns jobs to various Scheduler job classes. These job classes map the job to a consumer
group based on priority.
Note: With Oracle Database 11g, there is no job that is permanently associated with a specific
automated task. Therefore, it is not possible to use DBMS_SCHEDULER procedures to control the
behavior of automated tasks. Use the DBMS_AUTO_TASK_ADMIN procedures instead.

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


Controlling Automatic Maintenance Tasks

7 - 28 Copyright 2007, Oracle. All rights reserved.

Controlling Automatic Maintenance Tasks


The Automatic Maintenance Tasks feature determines whenand in what ordertasks are
performed. As a DBA, you can control the following:
If the maintenance window turns out to be inadequate for the maintenance workload, adjust the
duration and start time of the maintenance window.
Control the resource plan that allocates resources to the automated maintenance tasks during
each window.
Enable or disable individual tasks in some or all maintenance windows.
In a RAC environment, shift maintenance work to one or more instances by mapping
maintenance work to a service. Enabling the service on a subset of instances shifts maintenance
work to these instances.
As shown in the slide, Enterprise Manager is the preferred way to control Automatic Maintenance
Tasks. However, you can also use the DBMS_AUTO_TASK_ADMIN package.

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


Important I/O Metrics for Oracle Databases

Disk bandwidth Channel bandwidth

Metric = IOPS Metric = MBPS


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

OLTP DW/OLAP
(Small random I/O) (Large sequential I/O)

7 - 29 Copyright 2007, Oracle. All rights reserved.

Important I/O Metrics for Oracle Databases


We first briefly summarize the types of I/O issued by the Oracle Database processes.
The database I/O workload typically consists of small random I/O and large sequential I/O. Small
random I/O is more prevalent in an OLTP application environment in which each foreground reads a
data block into the buffer cache for updates and the changed blocks are written in batches by the
dbwr process. Large sequential I/O is common in an OLAP application environment. The OLTP
application performance depends on how fast a small I/O is serviced, which depends on how fast the
disk can spin and find the data. Large I/O performance depends on the capacity of the I/O channel
that connects the server to the storage array; large I/O throughput is better when the capacity of the
channel is larger.
IOPS (I/O per second): This metric represents the number of small random I/O that can be serviced
in a second. The IOPS rate mainly depends on how fast the disk media can spin. The IOPS rate from
a storage array can be increased either by adding more disk drives or by using disk drives with a
higher RPM (rotations per minute) rate.
MBPS (megabytes per second): The rate at which data can be transferred between the computing
server node and the storage array depends on the capacity of the I/O channel that is used to transfer
data. More data can be transferred through a wider pipe.

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


Important I/O Metrics for Oracle Databases (continued)
The throughput of a streaming data application depends on how fast this data can be transferred.
Throughput is measured by using the MBPS metric.
Even though the disks themselves have an upper limit on the amount of sequential data that they can
transfer, it is often channel capacity that limits the overall throughput of the system. For example, a
host connected to an NAS server through a GigE switch is limited by a transfer capacity of 128
MBPS. There are usually multiple disks in the NAS that can together provide more than 128 MBPS.
The channel resource becomes the limiting resource.
I/O latency: Latency is another important metric that is used in measuring the performance of an I/O
subsystem. Traditionally, latency is simply the time for the disk to access a particular sector on the
disk. But from the database point of view, latency represents all the time it takes for a submitted I/O
request to be serviced by the storage. In other words, it represents the overhead before the first byte
of a transfer arrives after an I/O request has been submitted. Latency values are more commonly used
for small random I/O when tuning a system. If there are too many I/O requests queued up against a
disk, the latency increases as the wait time in the queue increases. To improve the latency of I/O
requests, data is usually striped across multiple spindles so that all I/O requests to a file do not go to
the same disk. A higher latency usually indicates an overloaded system.
Other than the main resources mentioned above, there are also other storage array components that
can affect I/O performance. Array vendors provide caching mechanisms to improve read throughput,
but their real benefit is questionable in a database environment because Oracle Database uses caches
and read-ahead mechanisms so that data is available directly from RAM rather than from the disks.

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


I/O Calibration and Enterprise Manager

7 - 31 Copyright 2007, Oracle. All rights reserved.

I/O Calibration and Enterprise Manager


To determine the previously discussed I/O metrics, you can use the I/O Calibration tool from the
Enterprise Manager Performance page or PL/SQL. I/O Calibration is a modified version of the
ORION tool and is based on the asynchronous I/O library. Because calibration requires issuing
enough I/O to saturate the storage system, any performance-critical sessions will be negatively
impacted. Thus, you should run I/O calibration only when there is little activity on your system.
I/O Calibration takes approximately 10 minutes to run. You can launch an I/O Calibration task
directly from Enterprise Manager (as shown in the slide). You do this by clicking the Performance
tab. On the Performance page, you can click the I/O tab and then the I/O Calibration button.
On the I/O Calibration page, specify the approximate number of physical disks attached to your
database storage system as well as the maximum tolerable latency for a single-block I/O request.
Then, in the Schedule section of the I/O Calibration page, specify when to execute the calibration
operation. Click the Submit button to create a corresponding Scheduler job.
On the Scheduler Jobs page, you can see the amount of time it takes for the calibration task to run.
When finished, view the results of the calibration operation on the I/O Calibration page: maximum
I/O per second, maximum megabytes per second, and average actual latency metrics.

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


I/O Calibration and the PL/SQL Interface

SQL> exec dbms_resource_manager.calibrate_io( -


num_disks=>1, -
max_latency=>10, -
max_iops=>:max_iops, -
max_mbps=>:max_mbps, -
actual_latency=>:actual_latency);

PL/SQL procedure successfully completed.

SQL> SELECT max_iops, max_mbps, max_pmbps, latency


2 FROM DBA_RSRC_IO_CALIBRATE;

MAX_IOPS MAX_MBPS MAX_PMBPS LATENCY


---------- ---------- ---------- ----------
137 12 6 64

7 - 32 Copyright 2007, Oracle. All rights reserved.

I/O Calibration and the PL/SQL Interface


You can run the I/O Calibration task by using the PL/SQL interface. Execute the CALIBRATE_IO
procedure from the DBMS_RESOURCE_MANAGER package. This procedure calibrates the I/O
capabilities of the storage. The calibration status and results are available from the
V$IO_CALIBRATION_STATUS and DBA_RSRC_IO_CALIBRATE views.
Here is a brief description of the parameters you can specify for the CALIBRATE_IO procedure:
num_disks: Approximate number of physical disks in the database storage
max_latency: Maximum tolerable latency (in milliseconds) for database-block-sized I/O
requests
max_iops: Maximum number of I/O requests per second that can be sustained. The I/O
requests are randomly distributed, database-block-sized reads.
max_bps: Maximum throughput of I/O that can be sustained (in megabytes per second). The
I/O requests are randomly distributed 1 MB reads.
actual_latency: Average latency of database-block-sized I/O requests at max_iops rate
(in milliseconds)
Usage notes:
Only users with the SYSDBA privilege can run this procedure.
Only one calibration can run at a time. If another calibration is initiated at the same time, it fails.
For a RAC database, the workload is simultaneously generated from all instances.
The latency time is computed only when the TIMED_STATISTICS initialization parameter is
set to TRUE (which is set when STATISTICS_LEVEL is set to TYPICAL or ALL).

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


I/O Statistics: Overview

V$IOSTAT_FUNCTION

AWR and EM

.
V$IOSTAT_FILE

V$IOSTAT_CONSUMER_GROUP

7 - 33 Copyright 2007, Oracle. All rights reserved.

I/O Statistics: Overview


To give a consistent set of statistics for all I/O issued from an Oracle instance, Oracle Database 11g
introduces a set of virtual views that collect I/O statistics in three dimensions:
RDBMS components: Components are grouped by their functionality into 12 categories (shown
in the slide).
When Resource Management is enabled, I/O statistics are collected for all consumer groups that
are part of the currently enabled resource plan.
I/O statistics are also collected for the individual files that have been opened.
Each dimension has statistics for read and write operations. Since read/write can occur in single
block or multiblock operations, they are separated into four different operations (as shown in the
slide). For each operation type, the number of corresponding requests and the amount of megabytes
are cumulated. In addition to these, the total I/O wait time in milliseconds and the number of total
waits are also cumulated for both component and consumer group statistics.
For file statistics, total service time in microseconds is accumulated, in addition to statistics for single
block reads.
Virtual views show cumulative values for statistics. Component and consumer group statistics are
transformed into AWR metrics that are sampled regularly and stored in the AWR repository. You
can retrieve those metrics across a timeline directly on the Performance page of Enterprise Manager.
Note: V$IOSTAT_NETWORK collects network I/O statistics that are related to accessing files on a
remote database instance.
Oracle Database 11g: New Features for Administrators 7 - 33
I/O Statistics and Enterprise Manager

7 - 34 Copyright 2007, Oracle. All rights reserved.

I/O Statistics and Enterprise Manager


You can retrieve I/O statistics directly on the Performance page in Enterprise Manager. On the
Performance page, click the I/O subtab located under the Average Active Session graph.
On the I/O subpage, you see a breakdown of I/O statistics on three possible dimensions: I/O
Function, I/O Type, and Consumer Group. Select one of the options to look at the corresponding
dimension graphs. The slide shows the two graphs corresponding to the I/O function dimension:
I/O Megabytes per Second (by RDBMS component)
I/O Requests per Second (by RDBMS component)
Note: The Others RDBMS component category corresponds to everything that is not directly
issued from SQL (for example, PL/SQL and Java).

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


I/O Statistics and Enterprise Manager

7 - 35 Copyright 2007, Oracle. All rights reserved.

I/O Statistics and Enterprise Manager (continued)


From the I/O Function statistic graphs, you can drill down to a specific component by clicking that
component. In the example in the slide, you drill down to the Buffer Cache Reads component. This
takes you to the I/O Rates by I/O Function page, where you can see three important graphs for that
particular component: MBPS, IOPS, and wait time.

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


Practices 7-2 and 7-3: Overview

These practices cover the following topics:


Monitoring the performance of AUTOTASK jobs
Adjusting the resources and windows for AUTOTASK
jobs
Calibrating I/O resources

7 - 36 Copyright 2007, Oracle. All rights reserved.

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


Resource Manager: New EM Interface

7 - 37 Copyright 2007, Oracle. All rights reserved.

Resource Manager: New EM Interface


Using Enterprise Manager, you can access the Resource Manager section from the Server page.
The Resource Manager section is organized in the same way as the Database Resource Manager.
Clicking the Getting Started link takes you to the Getting Started with Database Resource Manager
page, which provides a brief description of each step as well as the links to the corresponding pages.

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


Resource Plans Created by Default

7 - 38 Copyright 2007, Oracle. All rights reserved.

Resource Plans Created by Default


When you create an Oracle 11g database, the Resource Plans (shown in the slide) are created by
default. However, none of these plans are active by default.

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


Default Plan

7 - 39 Copyright 2007, Oracle. All rights reserved.

Default Plan
The slide shows the properties of DEFAULT_PLAN. Note that there are no limits for its thresholds.
As you can see, Oracle Database 11g introduces two new I/O limits that you can define as thresholds
in a Resource Plan.

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


I/O Resource Limit Thresholds

7 - 40 Copyright 2007, Oracle. All rights reserved.

I/O Resource Limit Thresholds


When you create a Resource Plan directive, you can specify the I/O resource limits. The example in
the slide shows how to do this in both Enterprise Manager and PL/SQL.
You can specify the following two arguments:
switch_io_megabytes: Specifies the amount of I/O (in MB) that a session can issue before
an action is taken. Default is NULL, which means unlimited.
switch_io_reqs: Specifies the number of I/O requests that a session can issue before an
action is taken. Default is NULL, which means unlimited.

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


Resource Manager Statistics

7 - 41 Copyright 2007, Oracle. All rights reserved.

Resource Manager Statistics


You can also look at the Resource Manager Statistics page, which displays statistics for only the
current active plan.

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


New Scheduler Feature: Lightweight Jobs

Persistent lightweight jobs:


Created from a job template
Recoverable
JOB_STYLE => LIGHTWEIGHT

7 - 42 Copyright 2007, Oracle. All rights reserved.

New Scheduler Feature: Lightweight Jobs


Some customers need to create hundreds of jobs each second. With regular jobs, each job creates a
database object describing the job, modifying several tables, and creating redo in the process. In the
Oracle Database 11g Scheduler, there is a persistent lightweight job. The goal of a lightweight job is
to reduce the overhead and the time required to start a job. A minimal amount of metadata is created
for the job. This reduces the time required and the redo created when the job starts.
To achieve these goals, the lightweight job has a small footprint on disk for the job metadata and for
storing run-time data. The footprint on disk also makes recovery and load balancing possible in RAC
environments. The lightweight job is always created from a job template, which can be a stored
procedure or a program. The stored procedure holds all the information needed for the job. A few job
attributes may be set (such as job arguments).
Job templates are created by using the DBMS_SCHEDULER.CREATE_PROGRAM procedures.
Oracle Database 11g continues to support the database object-based jobs that have existed since
Oracle Scheduler was first introduced in Oracle 10g. Lightweight jobs are not intended to replace
these jobs because each job type has its own advantages and gives you the flexibility to choose a job
based on your needs.

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


Choosing the Right Job

Regular job
Highest overhead
Best recovery
Most flexible
Persistent lightweight job
Less overhead
Some recovery
Limited change to attributes

7 - 43 Copyright 2007, Oracle. All rights reserved.

Choosing the Right Job


The advantages and disadvantages of the types of jobs are as follows:
A regular job offers maximum flexibility but does entail a significant overhead in create/drop
performance. A job can be created with a single command. Users have fine-grained control of
privileges on the job and can also use programs or stored procedures owned by other users. A
regular job requires the job database object to be created and dropped. This action updates
several tables and the associated redo. Users who are creating a relatively small number of jobs
that run relatively infrequently should choose regular jobs.
A persistent lightweight job has a significant improvement in create/drop time because it does
not have the overhead of creating a database object. Every lightweight job is created from a job
template, which is stored as a program. Because persistent lightweight jobs write state
information to disk at run time, only a small improvement is expected in execution. There are
several limitations to persistent lightweight jobs:
- Users cannot set privileges on these jobs. Instead, they inherit their privileges from the
parent job template.
- The use of a template is mandatory. It is not possible to create a fully self-contained
persistent lightweight job.
- Only certain job attributes are available to be set, such as JOB_ARGUMENTS.
Lightweight jobs are most useful when the user needs to create a large number of jobs in a very
short time (from 10 to 100 jobs a second) and has a library of programs (job templates) available
for use.
Oracle Database 11g: New Features for Administrators 7 - 43
Creating a Single Lightweight Job

Specify time and frequency


DBMS_SCHEDULER.CREATE_JOB (
job_name => 'my_lightweight_job1',
program_name => 'MY_PROG',
repeat_interval=> 'FREQ=DAILY;BY_HOUR=9',
end_time => '30-APR-07 04.00.00 AM CST',
job_style => 'LIGHTWEIGHT');

Use predefined schedule


DBMS_SCHEDULER.CREATE_JOB (
job_name => 'my_lightweight_job2',
program_name => 'MY_PROG',
schedule_name => 'MY_SCHED',
job_style => 'LIGHTWEIGHT');

7 - 44 Copyright 2007, Oracle. All rights reserved.

Creating a Single Lightweight Job


The DBMS_SCHEDULER package has overloaded a few packages to allow the lightweight jobs to be
created with a minimum of new syntax. Lightweight jobs have very few parameters that can be
specified: job arguments and schedule. The rest of the metadata for the job is inherited from the job
template, including privileges. The template for a lightweight job must be a PL/SQL block or a
stored procedure. Lightweight jobs must be created in PL/SQL by using the DBMS_SCHEDULER
package. The JOB_STYLE argument is not exposed in EM.
In the first example in the slide, MY_PROG is the job template, and the schedule is created as part of
the CREATE_JOB method.
In the second example, the schedule is applied from a named schedule.
An example of a simple template is the following:
BEGIN
DBMS_SCHEDULER.CREATE_PROGRAM(
program_name=>'"SYSTEM"."MY_PROG"',
program_action=>
'DECLARE time_now DATE;
BEGIN
SELECT SYSDATE INTO time_now FROM DUAL;
END;',
program_type=>'PLSQL_BLOCK',
enabled=>TRUE);
END;
Oracle Database 11g: New Features for Administrators 7 - 44
Creating an Array of Lightweight Jobs

1. Declare variables of types sys.job and


sys.job_array.
DECLARE
newjob sys.job;
newjobarr sys.job_array;

2. Initialize the job array.


BEGIN
newjobarr := SYS.JOB_ARRAY();

3. Size the job array to hold the number of jobs needed.


newjobarr.EXTEND(100);

7 - 45 Copyright 2007, Oracle. All rights reserved.

Creating an Array of Lightweight Jobs


Using a job array is a more efficient way to create a set of jobs. This also applies to lightweight jobs.
The job array type and the CREATE_JOBS procedure are new to the DBMS_SCEHDULER package
in Oracle Database 11g.
In the example in the slide, 100 job specifications are created in a job array and submitted to the job
queue in a single transaction. Notice that, for a lightweight job, there is a very limited amount of
information needed. In this example, the start_time parameter defaults to NULL, so the job is
scheduled to start immediately. The example continues on the next two pages.
1. Declare the variable to hold a job definition and a job array variable.
2. Initialize the job array by using the SYS.JOB_ARRAY constructor. This creates a place for one
job in the array.
3. Set the size of the array to the number of expected jobs.
Note: If the array is very small, performance is not significantly better than submitting a single job.

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


Creating an Array of Lightweight Jobs

4. Place jobs in the job array.

FOR i IN 1..100 LOOP


newjob := SYS.JOB(job_name => 'LWTJK'||to_char(i),
job_style => 'LIGHTWEIGHT',
job_template => 'MY_PROG',
enabled => TRUE );
newjobarr(i) := newjob;
END LOOP;

5. Submit the job array as one transaction.


DBMS_SCHEDULER.CREATE_JOBS(newjobarr,
'TRANSACTIONAL');

7 - 46 Copyright 2007, Oracle. All rights reserved.

Creating an Array of Lightweight Jobs (continued)


4. Create each job and place it in the array. In this example, the only difference is the name of the
job. The start_time variable of the job is omitted and defaults to NULL, indicating that the
job will run immediately.
5. Use the CREATE_JOBS procedure to submit all jobs in the array as one transaction.
The full code of this example is as follows:
DECLARE
newjob sys.job;
newjobarr sys.job_array;
BEGIN
-- Create an array of JOB object types
newjobarr := sys.job_array();

-- Allocate sufficient space in the array


newjobarr.extend(100);

-- Add definitions for jobs


FOR i IN 1..100 LOOP
-- Create a JOB object type
newjob := sys.job(job_name => 'LWTJK' || to_char(i),
job_style => 'LIGHTWEIGHT',
job_template => 'PROG_1',
enabled => TRUE );

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


Creating an Array of Lightweight Jobs (continued)
-- Add job to the array
newjobarr(i) := newjob;
END LOOP;

-- Call CREATE_JOBS to create jobs in one transaction


DBMS_SCHEDULER.CREATE_JOBS(newjobarr, 'TRANSACTIONAL');

END;
/

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


Viewing Lightweight Jobs in the Dictionary

View lightweight jobs in *_SCHEDULER_JOBS:


SQL> SELECT job_name, job_style, program_name
2 FROM USER_SCHEDULER_JOBS;

JOB_NAME JOB_STYLE PROGRAM_NAME


----------------- ----------- -------------------
LWTJX LIGHTWEIGHT PROG_3

View job arguments with *_SCHEDULER_JOB_ARGS:


SQL> select job_name, argument_name, argument_type, value
2 FROM USER_SCHEDULER_JOB_ARGS;

JOB_NAME ARGUMENT_NAME ARGUMENT_TYPE VALUE


---------- -------------- -------------- ----------
LWTJX ARG1 VARCHAR2 TEST_VALUE

7 - 48 Copyright 2007, Oracle. All rights reserved.

Viewing Lightweight Jobs in the Dictionary


In Oracle Database 11g, changes to dictionary views to support lightweight jobs are minimal.
No new views are added.
Lightweight jobs are visible through the same views as are regular jobs:
DBA_SCHEDULER_JOBS, ALL_SCHEDULER_JOBS, and USER_SCHEDULER_JOBS
Arguments to lightweight jobs are visible through the same views as are those of regular jobs:
DBA_SCHEDULER_JOB_ARGS, ALL_SCHEDULER_JOB_ARGS, and
USER_SCHEDULER_JOB_ARGS
Because lightweight jobs are not database objects, they are not visible through the
DBA_OBJECTS, ALL_OBJECTS, and USER_OBJECTS views.

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


Practice 7-4 Overview:

This practice covers the creation of lightweight Scheduler


jobs.

7 - 49 Copyright 2007, Oracle. All rights reserved.

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


Summary

In this lesson, you should have learned how to:


Create AWR baselines for future time periods
Identify the views that capture foreground statistics
Control automated maintenance tasks
Use Resource Manager I/O calibration
Use lightweight jobs with the Scheduler

7 - 50 Copyright 2007, Oracle. All rights reserved.

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


Performance
Enhancements

Copyright 2007, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to:


Use the new features of ADDM
Use Automatic Memory Management
Use statistics enhancements

8-2 Copyright 2007, Oracle. All rights reserved.

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


ADDM Enhancements in Oracle Database 11g

ADDM for RAC


Directives (finding suppression)
DBMS_ADDM package

8-3 Copyright 2007, Oracle. All rights reserved.

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


Oracle Database 11g: Automatic Database
Diagnostic Monitor for RAC
Database ADDM

Self-diagnostic engine

Instance ADDM

AWR

Inst1 InstN

8-4 Copyright 2007, Oracle. All rights reserved.

Oracle Database 11g: Automatic Database Diagnostic Monitor for RAC


Oracle Database 11g offers an extension to the set of functionality that increases the databases
manageability by offering clusterwide analysis of performance. A special mode of Automatic
Database Diagnostic Monitor (ADDM) analyzes an Oracle Real Application Clusters (RAC)
database cluster and reports on issues that are affecting the entire cluster as well as on those that are
affecting individual instances. This mode is called database ADDM as opposed to instance ADDM,
which already existed with Oracle Database 10g.
Database ADDM for RAC is not just a report of reports but has independent analysis that is
appropriate for RAC.

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


Automatic Database Diagnostic Monitor
for RAC

Identifies the most critical performance problems for


the entire RAC cluster database
Runs automatically when taking AWR snapshots (the
default)
Performs database-wide analysis of:
Global resources (for example I/O and global locks)
High-load SQL and hot blocks
Global cache interconnect traffic
Network latency issues
Skew in instance response times
Is used by DBAs to analyze cluster performance

8-5 Copyright 2007, Oracle. All rights reserved.

Automatic Database Diagnostic Monitor for RAC


In Oracle Database 11g, you can create a period analysis mode for ADDM that analyzes the
throughput performance for an entire cluster. When the advisor runs in this mode, it is called
database ADDM. You can run the advisor for a single instance, which is equivalent to Oracle
Database 10g ADDM and is now called instance ADDM.
Instance ADDM has access to AWR data generated by all instances, thereby making the analysis of
global resources more accurate. Both database and instance ADDM run on continuous time periods
that can contain instance startup and shutdown. In the case of database ADDM, there may be several
instances that are shut down or started during the analysis period. You must maintain the same
database version throughout the entire time period, however.
Database ADDM runs automatically after each snapshot is taken. The automatic instance ADDM
runs are the same as in Oracle Database 10g. You can also perform analysis on a subset of instances
in the cluster. This is called partial analysis ADDM.
I/O capacity finding (the I/O system is overused) is a global finding because it concerns a global
resource affecting multiple instances. A local finding concerns a local resource or issue that affects a
single instance. For example, a CPU-bound instance results in a local finding about the CPU.
Although ADDM can be used during application development to test changes to either the
application, the database system, or the hosting machines, database ADDM is targeted at DBAs.

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


EM Support for ADDM for RAC

Cluster Database home page:

8-6 Copyright 2007, Oracle. All rights reserved.

EM Support for ADDM for RAC


Oracle Database 11g Enterprise Manager displays the ADDM analysis on the Cluster Database home
page. The Findings table is displayed in the ADDM Performance Analysis section.
For each finding, the Affected Instances column displays the number (m of n) of instances affected.
The display also indicates the percentage impact for each instance. Drilling down further on the
findings takes you to the Performance Findings Detail page.

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


EM Support for ADDM for RAC

Finding History page:

8-7 Copyright 2007, Oracle. All rights reserved.

EM Support for ADDM for RAC (continued)


On the Performance Finding Details page, click the Finding History button to see a page with a chart
on the top plotting the impact in active sessions for the findings over time. The default display period
is 24 hours. The drop-down list supports viewing for seven days.
At the bottom of the display, a table similar to the results section is shown, displaying all the findings
for this named finding.
On this page, you set filters on the findings results. Different types of findings (CPU, logins, SQL,
and so on) have different kinds of criteria for filtering.
Note: Only automatic runs of ADDM are considered for the Finding History. These results reflect the
unfiltered results only.

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


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, 1, 2);
SQL> END;

GET_REPORT procedure for seeing the result:

SQL> SELECT dbms_addm.get_report(:tname) FROM DUAL;

8-8 Copyright 2007, Oracle. All rights reserved.

Using the DBMS_ADDM Package


The DBMS_ADDM package eases the ADDM management. It consists of the following procedures
and 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 1,2: Start and end snapshot

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


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
----------------------------------------
Top Segments by I/O
Top SQL by "Cluster" Wait
. . .
Undersized Redo Log Buffer
Undersized SGA
Undersized Shared Pool
Undersized Streams Pool

8-9 Copyright 2007, Oracle. All rights reserved.

Advisor Named Findings and Directives


Oracle Database 10g introduced the advisor framework and various advisors to help DBAs manage
databases 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.

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


Using the DBMS_ADDM Package

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',
5 2,
6 10);
7 :tname := 'my instance ADDM task';
8 dbms_addm.analyze_inst(:tname, 1, 2);
9 END;
10 /
SQL> SELECT dbms_addm.get_report(:tname) from dual;

Possible findings in DBA_ADVISOR_FINDING_NAMES


8 - 10 Copyright 2007, Oracle. All rights reserved.

Using the DBMS_ADDM Package


You can use possible finding names to query the findings repository to get all occurrences of that
specific 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.

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


Using the DBMS_ADDM Package

Procedures to add directives:


INSERT_FINDING_DIRECTIVE
INSERT_SQL_DIRECTIVE
INSERT_SEGMENT_DIRECTIVE
INSERT_PARAMETER_DIRECTIVE
Procedures to delete directives:
DELETE_FINDING_DIRECTIVE
DELETE_SQL_DIRECTIVE
DELETE_SEGMENT_DIRECTIVE
DELETE_PARAMETER_DIRECTIVE

8 - 11 Copyright 2007, Oracle. All rights reserved.

Using the DBMS_ADDM Package (continued)


Additional PL/SQL directive procedures:
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
Long syntax for parameters would again help here.
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.

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


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:
DBA_ADVISOR_FINDINGS
USER_ADVISOR_FINDINGS
DBA_ADVISOR_RECOMMENDATIONS
USER_ADVISOR_RECOMMENDATIONS
DBA_ADVISOR_ACTIONS
USER_ADVISOR_ACTIONS

8 - 12 Copyright 2007, Oracle. All rights reserved.

Modified Advisor Views


The views containing advisor findings, recommendations, and actions have been enhanced by adding
the FILTERED column.

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


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
corresponding advisor views
DBA{USER}_ADDM_FDG_BREAKDOWN: Displays the
contribution for each finding from the different
instances for database and partial ADDM

8 - 13 Copyright 2007, Oracle. All rights reserved.

New ADDM Views


For a complete description of the available procedures, see the Oracle Database 11g documentation
set.

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


Oracle Database 10g SGA Parameters

With ASMM, 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 parameters
DB_KEEP_CACHE_SIZE LOG_BUFFER
SHARED_POOL_SIZE
DB_CACHE_SIZE
LARGE_POOL_SIZE DB_RECYCLE_CACHE_SIZE
SGA_MAX_SIZE
JAVA_POOL_SIZE
STREAMS_POOL_SIZE DB_nK_CACHE_SIZE

SGA_TARGET

8 - 14 Copyright 2007, Oracle. All rights reserved.

Oracle Database 10g SGA Parameters


As shown in the slide, the five most important pools are automatically tuned when Automatic Shared
Memory Management (ASMM) is activated. These parameters are called auto-tuned parameters.
The second category, called manual dynamic parameters, comprises parameters that can be manually
resized without having to shut down the instance but are not automatically tuned by the system.
The last category, manual static parameters, includes the parameters that are fixed in size and cannot
be resized without first shutting down the instance.

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


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)
WORKAREA_SIZE_POLICY:
Optional
Can be dynamically modified at the instance or session
level
Enables fallback to static SQL memory management for a
particular session

8 - 15 Copyright 2007, Oracle. All rights reserved.

Oracle Database 10g PGA Parameters


PGA_AGGREGATE_TARGET specifies the target aggregate PGA memory that is available to all
server 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, we throw an external error ORA-04032 at
startup.

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


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. In Oracle Database 10g,
PGA_AGGREGATE_TARGET controls work areas allocated by dedicated and shared connections.

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


Oracle Database 10g Memory Advisors

Buffer Cache Advice (introduced in 9i R1):


V$DB_CACHE_ADVICE
Predicts physical read times for different cache sizes
Shared Pool Advice (in 9i R2):
V$SHARED_POOL_ADVICE
Predicts parse times for different sizes of shared pool
Java Pool Advice (in 9i R2):
V$JAVA_POOL_ADVICE
Predicts Java class load time for Java pool sizes
Streams Pool Advice (10g R2)
V$STREAMS_POOL_ADVICE
Predicts spill and unspill activity time for various sizes

8 - 17 Copyright 2007, Oracle. All rights reserved.

Oracle Database 10g Memory Advisors


To help you size the most important SGA components, the advisors in the slide have been introduced
in Oracle Database 11g:
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 11g: New Features for Administrators 8 - 17


Oracle Database 10g Memory Advisors

SGA Target Advice (introduced in 10g R2):


V$SGA_TARGET_ADVICE view
Estimates the DB time for different SGA target sizes
based on current size
PGA Target Advice (introduced in 9i R1):
V$PGA_TARGET_ADVICE view
Predicts the PGA cache hit ratio for different PGA sizes
ESTD_TIME time column added in 11g R1
For all advisors, STATISTICS_LEVEL must be set to at
least TYPICAL.

8 - 18 Copyright 2007, Oracle. All rights reserved.

Oracle Database 10g Memory Advisors (continued)


In Oracle Database 10g, the SGA Advisor shows the improvement in DB time that can be
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.

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


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

Untunable Untunable Memory target Untunable


PGA PGA PGA
PGA memory

Free t arge
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
SGA memory

Large pool

Shared pool Shared pool Shared pool

Java pool Java pool Java pool


Streams pool Streams pool Streams pool

Other SGA Other SGA Other SGA

OLTP BATCH BATCH

8 - 19 Copyright 2007, Oracle. All rights reserved.

Automatic Memory Management: Overview


With Automatic Memory Management, the system causes an indirect transfer of memory from SGA
to 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.

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


Automatic Memory Management: Overview

11g 11g
350 MB 350 MB
Memory Memory
max target max target
300 MB
Memory target

250 MB
Memory target

ALTER SYSTEM SET


MEMORY_TARGET=300M;

8 - 20 Copyright 2007, Oracle. All rights reserved.

Automatic Memory Management: Overview (continued)


The simplest way to manage memory is to allow the database to automatically manage and tune it for
you. To do so (on most platforms), you only have to set 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: New Features for Administrators 8 - 20


Oracle Database 11g Memory Parameters

MEMORY_MAX_TARGET
SGA_MAX_SIZE

MEMORY_TARGET

SGA_TARGET PGA_AGGREGATE_TARGET

SHARED_POOL_SIZE
Others
DB_CACHE_SIZE
LARGE_POOL_SIZE
JAVA_POOL_SIZE
STREAMS_POOL_SIZE

DB_KEEP_CACHE_SIZE LOG_BUFFER
DB_RECYCLE_CACHE_SIZE RESULT_CACHE_SIZE
DB_nK_CACHE_SIZE

8 - 21 Copyright 2007, Oracle. All rights reserved.

Oracle Database 11g Memory Parameters


The slide displays the memory initialization parameters hierarchy. Although you only have to set
MEMORY_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.

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


Automatic Memory Parameter Dependency
N Y Y
MT>0 MMT=0 MMT=MT
N

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

Y
SGA and PGA N
ST>0 are separately
Y
auto-tuned. ST=0 & PAT>0 ST=min(MT-PAT,SMS)
N
Only PGA N
is auto-tuned.
ST=60%MT
SGA and PGA cannot PAT=40%MT
grow and shrink automatically.

Both SGA and PGA can grow and shrink automatically.

8 - 22 Copyright 2007, Oracle. All rights reserved.

Automatic Memory Parameter Dependency


The slide illustrates the relationships among the various memory sizing parameters.
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_SIZE.
If SGA_TARGET is set and PGA_AGGREGATE_TARGET is not set, we 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, we 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. We have 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.

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


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, we
follow the same policy as we have 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 R2 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
of MEMORY_TARGET. If you omit the line for MEMORY_TARGET and include a value for
MEMORY_MAX_TARGET, the MEMORY_TARGET parameter defaults to zero. After startup, you can
then dynamically change MEMORY_TARGET to a nonzero value if it does not exceed the value of
MEMORY_MAX_TARGET.
Legend: In the slide, use the following list to translate abbreviations to parameter names:
MT = MEMORY_TARGET
MMT = MEMORY_MAX_TARGET
ST = SGA_TARGET
PAT = PGA_AGGREGATE_TARGET
SMS = SGA_MAX_SIZE

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


Enabling Automatic Memory Management

8 - 24 Copyright 2007, Oracle. All rights reserved.

Enabling Automatic Memory Management


You can enable Automatic Memory Management by using Enterprise Manager, as shown in the
slide.
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 database must be automatically restarted for your change to take effect.

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


Monitoring Automatic Memory Management

8 - 25 Copyright 2007, Oracle. All rights reserved.

Monitoring Automatic Memory Management


When Automatic Memory Management is enabled, you see a new graphical representation of the
history 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.

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


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
V$MEMORY_CURRENT_RESIZE_OPS has current memory
resize operations
All SGA and PGA equivalents are still in place for
backward compatibility

8 - 26 Copyright 2007, Oracle. All rights reserved.

Monitoring Automatic Memory Management (continued)


The following views provide information about dynamic resize operations:
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.

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


DBCA and Automatic Memory Management

8 - 27 Copyright 2007, Oracle. All rights reserved.

DBCA and Automatic Memory Management


With Oracle Database 11g, DBCA has new options to accommodate Automatic Memory
Management (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 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 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.

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


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

set_global_prefs
DB
set_database_prefs MS
_S
se TA
t| TS
ex get |
set_schema_prefs po d
rt | ele
im te
po
set_table_prefs rt
gather_*_stats DBA

exec dbms_stats.set_table_prefs('SH','SALES','STALE_PERCENT','13');

8 - 28 Copyright 2007, Oracle. All rights reserved.

Statistic Preferences: Overview


The automated statistics-gathering feature was introduced in Oracle Database 10g, Release 1 to
reduce 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.
The Statistic Preferences feature in Oracle Database 11g introduces flexibility so that you can rely
more 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. As a DBA, you can use the DBMS_STATS package to manage the gathering
statistics options shown in the slide.

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


Statistic Preferences: Overview (continued)
Basically, 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 preference values that are
specified in various ways take precedence from the outer circles to the inner ones (as shown in the
slide).
The last three highlighted options are new in 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.

Note: You can describe all the effective statistics preference settings for all relevant tables by using
the DBA_TAB_STAT_PREFS view.

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


Setting Global Preferences
with Enterprise Manager

8 - 30 Copyright 2007, Oracle. All rights reserved.

Setting Global Preferences with Enterprise Manager


It is possible to control global preference settings by using Enterprise Manager. You do so on the
Manage 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.

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


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


Global
Q1 1970 Q2 1970 Q1 2007 Q1 1970 Q2 1970 Q1 2007 Q1 1970 Q2 1970 Q1 2007
statistics

GRANULARITY=GLOBAL% & INCREMENTAL=TRUE

8 - 31 Copyright 2007, Oracle. All rights reserved.

Partitioned Tables and Incremental Statistics: Overview


For a partitioned table, the system maintains both the statistics on each partition and the overall
statistics 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 we have a table that stores the
sales transactions. We 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 tablesespecially 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.

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


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.

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


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.
You are encouraged to use AUTO_SAMPLE_SIZE.
Otherwise, the old row sample technique is used.

8 - 33 Copyright 2007, Oracle. All rights reserved.

Hash-Based Sampling for Column Statistics


For query optimization, it is essential to have a good estimate of the number of distinct values. By
default, 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 samplingbased 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 old behavior when you specify sampling percentage.

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


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.

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


Multicolumn Statistics: Overview
VEHICLE
MAKE MODEL
1

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',-
method_opt=>'for all columns size 1 for columns (make,model) size 3'); 3

DBA_STAT_EXTENSIONS VEHICLE SYS_STUF3GLKIOP5F4B0BTTCFTMX0W

MAKE MODEL
4

S(MAKE MODEL)=S(MAKE,MODEL)

8 - 35 Copyright 2007, Oracle. All rights reserved.

Multicolumn Statistics: Overview


With Oracle Database 10g, the query optimizer takes into account correlation between columns when
computing 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.

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


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).
Notes
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
After creation, you can retrieve the statistics extensions by using the
ALL|DBA|USER_STAT_EXTENSIONS views.

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


Expression Statistics: Overview

CREATE INDEX upperidx ON VEHICLE(upper(MODEL))

VEHICLE
MODEL

VEHICLE
MODEL Still possible

Recommended

VEHICLE DBA_STAT_EXTENSIONS
S(upper( MODEL))=0.01 MODEL
SYS_STU3FOQ$BDH0S_14NGXFJ3TQ50

select dbms_stats.create_extended_stats('jfv','vehicle','(upper(model))') from


dual;
exec dbms_stats.gather_table_stats('jfv','vehicle',-
method_opt=>'for all columns size 1 for columns (upper(model)) size 3');

8 - 37 Copyright 2007, Oracle. All rights reserved.

Expression Statistics: Overview


Predicates involving expressions on columns are a significant issue for the query optimizer. When
computing 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.

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


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

IMPORT_TABLE_STATS

expdp/impdp
PUBLISH_PENDING_STATS

EXPORT_PENDING_STATS

TEST

8 - 38 Copyright 2007, Oracle. All rights reserved.

Deferred Statistics Publishing: Overview


By default, the statistics gathering operation automatically stores the new statistics in the data
dictionary 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 statisticsdays 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.

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


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.
When you have tested the pending statistics and are satisfied with them, you can publish them as
current in your production environment by using the new
DBMS_STAT.PUBLISH_PENDING_STATS procedure.
Note: For more information about the DBMS_STATS package, see the PL/SQL Packages and Types
Reference.

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


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

Execute your workload from the same session. 4

exec dbms_stats.publish_pending_stats('SH','CUSTOMERS'); 5

8 - 40 Copyright 2007, Oracle. All rights reserved.

Deferred Statistics Publishing: Example


1. Use the SET_TABLE_PREFS procedure to set the PUBLISH option to FALSE. This prevents
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.

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


Summary

In this lesson, you should have learned how to:


Use the new features of ADDM
Use Automatic Memory Management
Use statistics enhancements

8 - 41 Copyright 2007, Oracle. All rights reserved.

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


Practice 8: Overview

This practice covers the following topics:


Using Automatic Memory Management
Using deferred optimizer statistics

8 - 42 Copyright 2007, Oracle. All rights reserved.

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


Partitioning and Storage-Related
Enhancements

Copyright 2007, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to:


Implement the new partitioning methods
Employ data compression
Create a SQL Access Advisor analysis session using
Enterprise Manager
Create a SQL Access Advisor analysis session using
PL/SQL
Set up a SQL Access Advisor analysis to get partition
recommendations

9-2 Copyright 2007, Oracle. All rights reserved.

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


Oracle Partitioning

Core functionality Performance Manageability


Oracle8 Range partitioning Static partition Basic maintenance
Global range indexes pruning operations: add,
drop, exchange

Oracle8i Hash and composite Partitionwise joins Merge operation


range-hash partitioning Dynamic pruning

Oracle9i List partitioning Global index


maintenance

Oracle9i R2 Composite range-list Fast partition split


partitioning

Oracle10g Global hash indexes Local Index


maintenance

Oracle10g R2 1M partitions per table Multidimensional Fast drop table


pruning

Oracle More composite choices Interval Partitioning


REF Partitioning Partition Advisor
Database 11g
Virtual Column Partitioning

9-3 Copyright 2007, Oracle. All rights reserved.

Oracle Partitioning
The slide summarizes the ten years of partitioning development at Oracle.
Note: REF partitioning enables pruning and partitionwise joins against child tables. While
performance seems to be the most visible improvement, do not forget about the rest. Partitioning
must address all business-relevant areas of performance, manageability, and availability.

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


Partitioning Enhancements

Interval partitioning
System partitioning
Composite partitioning enhancements
Virtual column-based partitioning
Reference partitioning

9-4 Copyright 2007, Oracle. All rights reserved.

Partitioning Enhancements
Partitioning is an important tool for managing large databases. Partitioning allows the DBA to
employ a divide and conquer methodology for managing database tables, especially as those tables
grow. Partitioned tables allow a database to scale for very large data sets while maintaining
consistent performance, without unduly impacting administrative or hardware resources.
Partitioning enables faster data access within an Oracle database. Whether a database has 10 GB or
10 TB of data, partitioning can speed up data access by orders of magnitude.
With the introduction of Oracle Database 11g, the DBA will find a useful assortment of partitioning
enhancements. These enhancements include:
Addition of interval partitioning
Addition of system partitioning
Composite partitioning enhancements
Addition of virtual column-based partitioning
Addition of reference partitioning

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


Interval Partitioning

Interval partitioning is an extension of range


partitioning.
Partitions of a specified interval are created when
inserted data exceeds all of the range partitions.
At least one range partition must be created.
Interval partitioning automates the creation of range
partitions.

9-5 Copyright 2007, Oracle. All rights reserved.

Interval Partitioning
Before the introduction of interval partitioning, the DBA was required to explicitly define the range
of values for each partition. The problem is explicitly defining the bounds for each partition does not
scale as the number of partitions grow.
Interval partitioning is an extension of range partitioning, which instructs the database to
automatically create partitions of a specified interval when data inserted into the table exceeds all of
the range partitions. You must specify at least one range partition. The range partitioning key value
determines the high value of the range partitions, which is called the transition point, and the
database creates interval partitions for data beyond that transition point.
Interval partitioning fully automates the creation of range partitions. Managing the creation of new
partitions can be a cumbersome and highly repetitive task. This is especially true for predictable
additions of partitions covering small ranges, such as adding new daily partitions. Interval
partitioning automates this operation by creating partitions on demand.
When using interval partitioning, consider the following restrictions:
You can specify only one partitioning key column, and it must be of NUMBER or DATE type.
Interval partitioning is not supported for index-organized tables.
You cannot create a domain index on an interval-partitioned table.

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


Interval Partitioning: Example

CREATE TABLE SH.SALES_INTERVAL


PARTITION BY RANGE (time_id)
INTERVAL (NUMTOYMINTERVAL(1,'month')) STORE IN (tbs1,tbs2,tbs3,tbs4)
(
PARTITION P1 values less than (TO_DATE('1-1-2002','dd-mm-yyyy')),
PARTITION P2 values less than (TO_DATE('1-1-2003','dd-mm-yyyy')),
PARTITION P3 values less than (TO_DATE('1-1-2004','dd-mm-yyyy')))
AS
SELECT *
FROM SH.SALES
WHERE TIME_ID < TO_DATE('1-1-2004','dd-mm-yyyy');

Automatically created
when you insert data

P1 P2 P3 Pi1 Pin

Range section Interval section


Transition point

9-6 Copyright 2007, Oracle. All rights reserved.

Interval Partitioning: Example


Consider the example in the slide, which illustrates the creation of an interval-partitioned table. The
original CREATE TABLE statement specifies four partitions with varying widths. This portion of the
table is range-partitioned. It also specifies that above the transition point of 1-1-2004, partitions are
created with a width of one month. These partitions are interval-partitioned. Partition Pi1 is
automatically created using this information when a row with a value corresponding to January 2004
is inserted into the table. The high bound of partition P3 represents a transition point. P3 and all
partitions below it (P1 and P2 in this example) are in the range section, while all partitions above it
fall into the interval section. The only argument to the INTERVAL clause is a constant of the interval
type. Currently, you can specify only one partitioning key column, and it must be of DATE or
NUMBER type.
You can use the optional STORE IN clause of the INTERVAL clause to specify one or more
tablespaces into which the database will store interval partition data in a round-robin fashion.

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


Moving the Transition Point: Example

PREVIOUS
< 01/01/07 INSERT INTO orders_interval ();
Transition point

Not yet
PREVIOUS materialized SYS_Px SYS_Py SYS_Pz SYS_Pt
< 01/01/07 < 01/08/06 < 01/11/06 < 01/12/06 < 01/03/08
Transition point

alter table orders_interval merge partitions


for(TO_DATE('15-10-2007','dd-mm-yyyy')),for(TO_DATE('15-11-2007','dd-mm-yyyy'))
into partition sys_p5z;

PREVIOUS SYS_Px SYS_Pz SYS_Pt


< 01/01/06 < 01/08/06 < 01/12/06 < 01/03/08
Transition point

9-7 Copyright 2007, Oracle. All rights reserved.

Moving the Transition Point: Example


The graphic in the slide shows you a typical Information Lifecycle Management (ILM) scenario
where after one year of automated partition creation, you merge the created partitions (SYS_Py and
SYS_Pz in the example) to move the transition point. You can then move the resulting partitions to
a different storage for ILM purposes.
The example assumes that you created a table called ORDERS_INTERVAL that has initially one
range partition called PREVIOUS, which holds orders from before 2007. The interval is defined to be
one month. Then during the year 2007 and 2008, some orders are inserted, and it is assumed that four
partitions are created. They are shown on the graphic. They are automatically named according to
some system rules.
Then you decide to merge the last two partitions of the year 2007 using the ALTER TABLE
statement shown in the slide. You must merge two adjacent partitions. Note the new extended
partition syntax that can be used to designate a partition without knowing its name. The syntax uses
an expression that must represent a possible value for the partition in question. This syntax works for
all cases when you have to reference a partition, whether it be range, list, interval, or hash. It supports
all operations such as drop, merge, split, and so on.
As a result of your MERGE operation, you can see that the transition point moved. The bottom part of
the graphic shows you the new range section that now contains three partitions.
Note: You can change the interval of an interval-partitioned table; the existing intervals remain
unaffected.
Oracle Database 11g: New Features for Administrators 9 - 7
System Partitioning

System partitioning:
Enables application-controlled partitioning for selected
tables
Provides the benefits of partitioning but the partitioning
and data placement are controlled by the application
Does not employ partitioning keys like other
partitioning methods
Does not support partition pruning in the traditional
sense

9-8 Copyright 2007, Oracle. All rights reserved.

System Partitioning
System partitioning enables application-controlled partitioning for arbitrary tables. This is mainly
useful when you develop your own partitioned domain indexes. The database simply provides the
ability to break down a table into meaningless partitions. All other aspects of partitioning are
controlled by the application. System partitioning provides the well-known benefits of partitioning
(scalability, availability, and manageability), but the partitioning and actual data placement are
controlled by the application.
The most fundamental difference between system partitioning and other methods is that system
partitioning does not have any partitioning keys. Consequently, the distribution or mapping of the
rows to a particular partition is not implicit. Instead, the user specifies the partition to which a row
maps by using partition-extended syntax when inserting a row.
Because system-partitioned tables do not have a partitioning key, the usual performance benefits of
partitioned tables are not available for system-partitioned tables. Specifically, there is no support for
traditional partition pruning, partitionwise joins, and so on. Partition pruning is achieved by
accessing the same partitions in the system-partitioned tables as those that were accessed in the base
table.
System-partitioned tables provide the manageability advantages of equipartitioning. For example, a
nested table can be created as a system-partitioned table that has the same number of partitions as the
base table. A domain index can be backed up by a system-partitioned table that has the same number
of partitions as the base table.
Oracle Database 11g: New Features for Administrators 9 - 8
System Partitioning: Example

CREATE TABLE systab (c1 integer, c2 integer)


PARTITION BY SYSTEM
(
PARTITION p1 TABLESPACE tbs_1,
PARTITION p2 TABLESPACE tbs_2,
PARTITION p3 TABLESPACE tbs_3,
PARTITION p4 TABLESPACE tbs_4
);

INSERT INTO systab PARTITION (p1) VALUES (4,5);


INSERT INTO systab PARTITION (p2) VALUES (150,2);

alter table systab merge partitions p1,p2 into partition p1;

9-9 Copyright 2007, Oracle. All rights reserved.

System Partitioning: Example


The syntax in the slide example creates a table with four partitions. Each partition can have different
physical attributes. INSERT and MERGE statements must use partition-extended syntax to identify a
particular partition that a row should go into. For example, the value (4,5) can be inserted into any
one of the four partitions given in the example.
Deletes and updates do not require the partition-extended syntax. However, because there is no
partition pruning, if the partition-extended syntax is omitted, the entire table is scanned to execute the
operation. Again, this example highlights the fact that there is no implicit mapping from rows to any
partition.

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


System Partitioning: Guidelines

The following operations are supported for system-


partitioned tables:
Partition maintenance operations and other DDL
operations
Creation of local indexes
Creation of local bitmapped indexes
Creation of global indexes
All DML operations
INSERT SELECT with partition-extended syntax:
INSERT INTO <table_name> PARTITION(<partition-name>) <subquery>

9 - 10 Copyright 2007, Oracle. All rights reserved.

System Partitioning: Guidelines


The following operations are supported for system-partitioned tables:
Partition maintenance operations and other DDLs (see exceptions below)
Creation of local indexes
Creation of local bitmapped indexes
Creation of global indexes
All DML operations
INSERT SELECT with partition-extended syntax.

Because of the peculiar requirements of system partitioning, the following operations are not
supported for system partitioning:
Unique local indexes are not supported because they require a partitioning key.
CREATE TABLE AS SELECT is not supported because there is no partitioning method. It is
not possible to distribute rows to partitions. Instead, you should first create the table and then
insert rows into each partition.
SPLIT PARTITION operations

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


Virtual ColumnBased Partitioning

Virtual column values are derived by the evaluation of a


function or expression.
Virtual columns can be defined within a CREATE or
ALTER table operation.
CREATE TABLE employees
(employee_id number(6) not null,

total_compensation as (salary *( 1+commission_pct))

Virtual column values are not physically stored in the


table row on disk, but are evaluated on demand.
Virtual columns can be indexed, and used in queries,
DML, and DDL statements like other table column types.
Tables and indexes can be partitioned on a virtual
column and even statistics can be gathered upon them.
9 - 11 Copyright 2007, Oracle. All rights reserved.

Virtual ColumnBased Partitioning


Columns of a table whose values are derived by computation of a function or an expression are
known as virtual columns. These columns can be specified during a CREATE or ALTER table
operation. Virtual columns share the same SQL namespace as other real table columns and conform
to the data type of the underlying expression that describes it. These columns can be used in queries
like any other table columns, thereby providing a simple, elegant, and consistent mechanism of
accessing expressions in a SQL statement.
The values for virtual columns are not physically stored in the table row on disk, rather they are
evaluated on demand. The functions or expressions describing the virtual columns should be
deterministic and pure, meaning the same set of input values should return the same output values.
Virtual columns can be used like any other table columns. They can be indexed, and used in queries,
DML, and DDL statements. Tables and indexes can be partitioned on a virtual column and even
statistics can be gathered upon them.
You can use virtual column partitioning to partition key columns defined on virtual columns of a
table. Frequently, business requirements to logically partition objects do not match existing columns
in a one-to-one manner. With the introduction of Oracle Database 11g, partitioning has been
enhanced to allow a partitioning strategy defined on virtual columns, thus enabling a more
comprehensive match of the business requirements.

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


Virtual ColumnBased Partitioning: Example

CREATE TABLE employees


(employee_id number(6) not null, first_name varchar2(30),
last_name varchar2(40) not null, emailvarchar2(25),
phone_number varchar2(20), hire_date date not null,
job_id varchar2(10) not null, salary number(8,2),
commission_pct number(2,2), manager_id number(6),
department_id number(4),
total_compensation as (salary *( 1+commission_pct))
)
PARTITION BY RANGE (total_compensation)
(
PARTITION p1 VALUES LESS THAN (50000),
PARTITION p2 VALUES LESS THAN (100000),
PARTITION p3 VALUES LESS THAN (150000),
PARTITION p4 VALUES LESS THAN (MAXVALUE)
);

9 - 12 Copyright 2007, Oracle. All rights reserved.

Virtual Column-Based Partitioning: Example


Consider the example in the slide. The EMPLOYEES table is created using the standard CREATE
TABLE syntax. The total_compensation column is a virtual column calculated by multiplying
the value of salary by the commission_pct plus one. The next statement declares
total_compensation (a virtual column) to be the partitioning key of the EMPLOYEES table.
Partition pruning takes place for virtual column partition keys when the predicates on the partitioning
key are of the following types:
Equality or Like
List
Range
Partition-extended names
Given a join operation between two tables, the optimizer recognizes when a partitionwise join (full or
partial) is applicable, decides whether to use it or not, and annotates the join properly when it decides
to use it. This applies to both serial and parallel cases.
In order to recognize full partitionwise joins, the optimizer relies on the definition of equipartitioning
of two objects; this definition includes the equivalence of the virtual expression on which the tables
were partitioned.

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


Reference Partitioning

A table can now be partitioned based on the partitioning


method of a table referenced in its referential constraint.
The partitioning key is resolved through an existing
parent/child relationship.
The partitioning key is enforced by active primary key or
foreign key constraints.
Tables with a parent/child relationship can be
equipartitioned by inheriting the partitioning key from
the parent table without duplicating the key columns.
Partitions are automatically maintained.

9 - 13 Copyright 2007, Oracle. All rights reserved.

Reference Partitioning
Reference partitioning provides the ability to partition a table based on the partitioning scheme of the
table referenced in its referential constraint. The partitioning key is resolved through an existing
parent/child relationship, which is enforced by active primary key or foreign key constraints. The
benefit of this is that tables with a parent/child relationship can be logically equipartitioned by
inheriting the partitioning key from the parent table without duplicating the key columns. The logical
dependency also automatically cascades partition maintenance operations, making application
development easier and less error prone.

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


Reference Partitioning: Benefit
Without using reference partitioning Reference partitioning

Range(ORDER_DATE)
Primary key (ORDER_ID)

Table ORDERS

Table
ORDER_ITEMS

Range(ORDER_DATE)
Foreign key (ORDER_ID)

Redundant storage/maintenance of ORDER_DATE Partition key inherited through PK/FK relationship

9 - 14 Copyright 2007, Oracle. All rights reserved.

Reference Partitioning: Benefit


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

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


Reference Partitioning: Example
CREATE TABLE orders
( order_id NUMBER(12) , order_date DATE,
order_mode VARCHAR2(8), customer_id NUMBER(6),
order_status NUMBER(2) , order_total NUMBER(8,2),
sales_rep_id NUMBER(6) , promotion_id NUMBER(6),
CONSTRAINT orders_pk PRIMARY KEY(order_id)
)
PARTITION BY RANGE(order_date)
(PARTITION Q105 VALUES LESS THAN (TO_DATE('1-4-2005','DD-MM-YYYY')),
PARTITION Q205 VALUES LESS THAN (TO_DATE('1-7-2005','DD-MM-YYYY')),
PARTITION Q305 VALUES LESS THAN (TO_DATE('1-10-2005','DD-MM-YYYY')),
PARTITION Q405 VALUES LESS THAN (TO_DATE('1-1-2006','DD-MM-YYYY')));

CREATE TABLE order_items


( order_id NUMBER(12) NOT NULL, line_item_id NUMBER(3) NOT NULL,
product_id NUMBER(6) NOT NULL, unit_price NUMBER(8,2),
quantity NUMBER(8),
CONSTRAINT order_items_fk
FOREIGN KEY(order_id) REFERENCES orders(order_id)
) PARTITION BY REFERENCE(order_items_fk);

9 - 15 Copyright 2007, Oracle. All rights reserved.

Reference Partitioning: Example


The example in the slide creates two tables:
ORDERS: Range-partitioned table partitioned on order_date. It is created with four
partitions, Q105, Q205, Q305, and Q405.
ORDER_ITEMS: Reference-partitioned child table:
- This table is created with four partitionsQ105, Q205, Q305, and Q405with each
containing rows corresponding to ORDERS in the respective parent partition.
- If partition descriptors are provided, the number of partitions described must be exactly
equal to the number of partitions or subpartitions in the referenced table.
- If the parent table is a composite-partitioned table, then the table will have one partition for
each subpartition of its parent.
- Partition bounds cannot be specified for the partitions of a reference-partitioned table. The
partitions of a reference-partitioned table can be named unless there is a conflict with
inherited names. In this case, the partition will have a system-generated name.
- Partitions of a reference-partitioned table will collocate with the corresponding partition of
the parent table, if no explicit tablespace is specified. As with other partitioned tables, you
can specify object-level default attributes, and partition descriptors that override object-
level defaults.
- It is not possible to disable the foreign key constraint of a reference-partitioned table.
- It is not permitted to add or drop partitions of a reference-partitioned table. However,
performing partition maintenance operations on the parent table is automatically cascaded
to the child table.
Oracle Database 11g: New Features for Administrators 9 - 15
Composite Partitioning Enhancements

Range top level


Range-Range RANGE, LIST, INTERVAL
List top level
SP1 SP1 SP1 SP1 SP1
List-List
List-Hash
SP2 SP2 SP2 SP2 SP2
List-Range
Interval top level SP3 SP3 SP3
SP3 SP3
Interval-Range
Interval-List SP4 SP4 SP4 SP4 SP4

Interval-Hash
LIST, RANGE, HASH

9 - 16 Copyright 2007, Oracle. All rights reserved.

Composite Partitioning Enhancements


Before the release of Oracle Database 11g, the only composite partitioning methods supported were
range-list and range-hash. With this new release, list partitioning can be a top-level partitioning
method for composite partitioned tables giving us list-list, list-hash, list-range, and range-range
composite methods. With the introduction of interval partitioning, interval-range, interval-list, and
interval-hash are now supported composite partitioning methods.
Range-Range Partitioning
Composite range-range partitioning enables logical range partitioning along two dimensions; for
example, range partition by order_date and range subpartition by shipping_date.
List-Range Partitioning
Composite list-range partitioning enables logical range subpartitioning within a given list partitioning
strategy; for example, list partition by country_id and range subpartition by order_date.
List-Hash Partitioning
Composite list-hash partitioning enables hash subpartitioning of a list-partitioned object; for
example, to enable partitionwise joins.
List-List Partitioning
Composite list-list partitioning enables logical list partitioning along two dimensions; for example,
list partition by country_id and list subpartition by sales_channel.

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


Range-Range Partitioning: Example

CREATE TABLE sales (


prod_id NUMBER(6) NOT NULL, cust_id NUMBER NOT NULL,
time_id DATE NOT NULL, channel_id char(1) NOT NULL,
promo_id NUMBER (6) NOT NULL,
quantity_sold NUMBER(3) NOT NULL,
amount_sold NUMBER(10,2) NOT NULL )
PARTITION BY RANGE (time_id)
SUBPARTITION BY RANGE (cust_id)
SUBPARTITION TEMPLATE
( SUBPARTITION sp1 VALUES LESS THAN (50000),
SUBPARTITION sp2 VALUES LESS THAN (100000),
SUBPARTITION sp3 VALUES LESS THAN (150000),
SUBPARTITION sp4 VALUES LESS THAN (MAXVALUE) )
(
PARTITION VALUES LESS THAN (TO_DATE('1-4-2007','DD-MM-YYYY')),
PARTITION VALUES LESS THAN (TO_DATE('1-7-2007','DD-MM-YYYY')),
PARTITION VALUES LESS THAN (TO_DATE('1-8-2007','DD-MM-YYYY')),
PARTITION VALUES LESS THAN (TO_DATE('1-1-2008','DD-MM-YYYY'))
);

9 - 17 Copyright 2007, Oracle. All rights reserved.

Composite Range-Range Partitioning: Example


Composite range-range partitioning enables logical range partitioning along two dimensions. In the
example in the slide, the SALES table is created and range-partitioned on time_id. Using a
subpartition template, the SALES table is subpartitioned by range using cust_id as the
subpartition key.
Because of the template, all partitions have the same number of subpartitions with the same bounds
as defined by the template. If no template is specified, a single default partition bound by
MAXVALUE (range) or DEFAULT value (list) is created.
Although the example illustrates the range-range methodology, the other new composite partitioning
methods use similar syntax and statement structure. All of the composite partitioning methods fully
support the existing partition pruning methods for queries involving predicates on the subpartitioning
key.

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


Table Compression: Overview

Oracle Database 11g extends compression for OLTP


data.
Support for conventional DML operations
(INSERT, UPDATE, DELETE)
New algorithm significantly reduces write overhead.
Batched compression ensures no impact for most OLTP
transactions.
No impact on reads
Reads may actually see improved performance due to
fewer I/Os and enhanced memory efficiency.

9 - 18 Copyright 2007, Oracle. All rights reserved.

Table Compression: Overview


The Oracle database was the pioneer in terms of compression technology for databases with the
introduction of table compression for bulk load operations in Oracle9i. Using this feature, you could
compress data at the time of performing bulk load using operations such as direct loads, or Create
Table As Select (CTAS). However, until now, compression was not available for regular data
manipulation operations such as INSERT, UPDATE, and DELETE. Oracle Database 11g extends the
compression technology to support these operations as well. Consequently, compression in Oracle
Database 11g can be used for all kinds of workload, be it online transaction processing (OLTP) or
data warehousing.
It is important to mention that table compression enhancements introduced in Oracle database 11g
are not just incremental changes. An enormous amount of work has gone into making sure that the
new compression technology has negligible impact on updates because any noticeable write time
penalty due to compression will not be acceptable in an OLTP environment. As a result, compression
technology in Oracle Database 11g is very efficient and could reduce the space consumption by 50
75%. And while you do that, not only your write performance does not degrade, but also your read
performance or queries improve. This is because unlike desktop-based compression techniques
where you have to wait for data to be uncompressed, Oracle technology reads the compressed data
(less fetches needed) directly and does not require any uncompress operation.
Note: Compression technology is completely application transparent. This means that you can use
this technology with any homegrown or packaged application such as SAP, Siebel, EBS, and so on.

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


Table Compression Concepts

Inserts are again


uncompressed.

Compressed
data
PCTFREE reached
triggers compression.
Uncompressed
data

Data block PCTFREE reached


triggers compression.
Header
PCTFREE
limit

Free
space
Inserts are
uncompressed.

9 - 19 Copyright 2007, Oracle. All rights reserved.

Table Compression Concepts


The slide shows you a data block evolution when that block is part of a compressed table. You
should read it from left to right. At the start, the block is empty and available for inserts. When you
start inserting into this block, data is stored in an uncompressed format (like for uncompressed
tables). However, as soon as you reach the PCTFREE of that block, the data is automatically
compressed, potentially reducing the space it originally occupied. This allows for new uncompressed
inserts to take place in the same block, until PCTFREE is reached again. At that point compression is
triggered again to reduce space occupation in the block.
Note: Compression eliminates holes created due to deletions and maximizes contiguous free space in
blocks.

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


Using Table Compression

Requires database compatibility level at 11.1 or greater


New syntax extends the COMPRESS keyword:
COMPRESS [FOR {ALL | DIRECT_LOAD} OPERATIONS]
FOR DIRECT_LOAD is the default: Refers to bulk load
operations from prior releases
FOR ALL OPERATIONS: OLTP + direct loads
Enable compression for new tables:
CREATE TABLE t1 COMPRESS FOR ALL OPERATIONS;

Enable compression on existing table:


ALTER TABLE t2 COMPRESS FOR ALL OPERATIONS;

Does not trigger compression on existing rows

9 - 20 Copyright 2007, Oracle. All rights reserved.

Using Table Compression


To use the new compression algorithm, you must flag your table with the COMPRESS FOR ALL
OPERATIONS clause. You can do so at table creation, or after creation. This is illustrated in the
examples given in the slide.
If you use the COMPRESS clause without specifying any FOR option, or if you use the COMPRESS
FOR DIRECT_LOAD OPERATIONS clause, you fall back to the old compression mechanism that
was available in earlier releases.
You can also enable compression at the partition or tablespace level. For example, you can use the
DEFAULT storage clause of the CREATE TABLESPACE command to optionally specify a
COMPRESS FOR clause.
Note: You can view compression flags for your tables using the COMPRESS and COMPRESS_FOR
columns in views such as DBA_TABLES and DBA_TAB_PARTITIONS.

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


SQL Access Advisor: Overview

What
partitions, indexes,
and MVs do I need SQL
to optimize Solution Access
my entire Advisor
workload?

DBA
No expertise
required Component
Workload
of CBO
Provides
implementation
script

9 - 21 Copyright 2007, Oracle. All rights reserved.

SQL Access Advisor: Overview


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

SQL Access
Advisor

SQL cache
Workload
Hypothetical

STS
Filter
Options

Indexes Materialized Materialized Partitioned


views views log objects

9 - 22 Copyright 2007, Oracle. All rights reserved.

SQL Access Advisor: Usage Model


SQL Access Advisor takes as input a workload that can be derived from multiple sources:
SQL cache, to take the current content of V$SQL
Hypothetical, to generate a likely workload from your dimensional model. This option is
interesting when your system is being initially designed.
SQL Tuning Sets, from the workload repository
SQL Access Advisor also provides powerful workload filters that you can use to target the tuning.
For example, a user can specify that the advisor should look at only the 30 most resource-intensive
statements in the workload, based on optimizer cost. For the given workload, the advisor then does
the following:
Simultaneously considers index solutions, materialized view solutions, partition solutions, or
combinations of all three
Considers storage for creation and maintenance costs
Does not generate drop recommendations for partial workloads
Optimizes materialized views for maximum query rewrite usage and fast refresh
Recommends materialized view logs for fast refresh
Recommends partitioning for tables, indexes, and materialized views
Combines similar indexes into a single index
Generates recommendations that support multiple workload queries

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


Possible Recommendations

Recommendation Comprehensive Limited


Add new (partitioned) index on table or materialized view. YES YES
Drop an unused index. YES NO
Modify an existing index by changing the index type. YES NO
Modify an existing index by adding columns at the end. YES YES
Add a new (partitioned) materialized view. YES YES
Drop an unused materialized view (log). YES NO
Add a new materialized view log. YES YES
Modify an existing materialized view log to add new YES YES
columns or clauses.
Partition an existing unpartitioned table or index. YES YES

9 - 23 Copyright 2007, Oracle. All rights reserved.

Possible Recommendations
SQL Access Advisor carefully considers the overall impact of recommendations and makes
recommendations by using only the known workload and supplied information. Two workload
analysis methods are available:
Comprehensive: With this approach, SQL Access Advisor addresses all aspects of tuning
partitions, materialized views, indexes, and materialized view logs. It assumes that the workload
contains a complete and representative set of application SQL statements.
Limited: Unlike the comprehensive workload approach, a limited workload approach assumes
that the workload contains only problematic SQL statements. Thus, advice is sought for
improving the performance of a portion of an application environment.
When comprehensive workload analysis is chosen, SQL Access Advisor forms a better set of global
tuning adjustments, but the effect may be a longer analysis time. As shown in the table, the chosen
workload approach determines the type of recommendations made by the advisor.
Note: Partition recommendations can work on only those tables that have at least 10,000 rows, and
workloads that have some predicates and joins on columns of NUMBER or DATE type. Partitioning
advices can be generated only on these types of columns. In addition, partitioning advices can be
generated only for single-column interval and hash partitions. Interval partitioning recommendations
can be output as range syntax but interval is the default. Hash partitioning is done to leverage only
partitionwise joins.

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


SQL Access Advisor Session: Initial Options

9 - 24 Copyright 2007, Oracle. All rights reserved.

SQL Access Advisor Session: Initial Options


The next few slides describe a typical SQL Access Advisor session. You can access the SQL Access
Advisor wizard through the Advisor Central link on the Database Home page or through individual
alerts or performance pages that may include a link to facilitate solving a performance problem. The
SQL Access Advisor wizard consists of several steps during which you supply the SQL statements to
tune and the types of access methods you want to use.
Use the SQL Access Advisor: Initial Options page to select a template or task from which to populate
default options before starting the wizard. You can click Continue to start the wizard or Cancel to
go back to the Advisor Central page.
Note: The SQL Access Advisor may be interrupted while generating recommendations, thereby
allowing the results to be reviewed.
For general information about using SQL Access Advisor, see the Overview of the SQL Access
Advisor section in the SQL Access Advisor lesson of the Oracle Data Warehousing Guide.

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


SQL Access Advisor Session: Initial Options

9 - 25 Copyright 2007, Oracle. All rights reserved.

SQL Access Advisor Session: Initial Options (continued)


If you choose the Inherit Options from a Task or Template option on the Initial Options page, you
are able to select an existing task, or an existing template to inherit SQL Access Advisors options.
By default, the SQLACCESS_EMTASK template is used.
You can view the various options defined by a task or a template by selecting the corresponding
object and clicking View Options.

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


SQL Access Advisor: Workload Source

9 - 26 Copyright 2007, Oracle. All rights reserved.

SQL Access Advisor: Workload Source


You can choose your workload source from three different sources:
Current and Recent SQL Activity: This source corresponds to SQL statements that are still
cached in your SGA.
Use an existing SQL Tuning Set: You also have the possibility to create and use a SQL Tuning
Set that holds your statements.
Hypothetical Workload: This option provides a schema that allows the advisor to search for
dimension tables and produce a workload. This is very useful to initially design your schema.
Using the Filter Options section, you can further filter your workload source. Filter options are:
Resource Consumption: Number of statements ordered by Optimizer Cost, Buffer Gets, CPU
Time, Disk Reads, Elapsed Time, Executions.
Users
Tables
SQL Text
Module IDs
Actions

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


SQL Access Advisor: Recommendation Options

9 - 27 Copyright 2007, Oracle. All rights reserved.

SQL Access Advisor: Recommendation Options


Use the Recommendations Options page to choose whether to limit the SQL Access Advisor to
recommendations based on a single access method. You can choose the type of structures to be
recommended by the advisor. If none of the three possible ones are chosen, the advisor evaluates
existing structures instead of trying to recommend new ones.
You can use the Advisor Mode section to run the advisor in one of two modes. These modes affect
the quality of recommendations as well as the length of time required for processing. In
Comprehensive mode, the Advisor searches a large pool of candidates resulting in recommendations
of the highest quality. In Limited mode, the advisor performs quickly, limiting the candidate
recommendations by working on the highest-cost statements only.

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


SQL Access Advisor: Recommendation Options

9 - 28 Copyright 2007, Oracle. All rights reserved.

SQL Access Advisor: Recommendation Options (continued)


You can choose Advanced Options to show or hide options that allow you to set space restrictions,
tuning options, and default storage locations. Use the Workload Categorization section to set options
for workload volatility and scope. For workload volatility, you can choose to favor read-only
operations or you can consider the volatility of referenced objects when forming recommendations.
For workload scope, you can select Partial Workload, which does not include recommendations to
drop unused access structures, or Complete Workload, which includes recommendations to drop
unused access structures.
Use the Space Restrictions section to specify a hard space limit, which forces the advisor to produce
only recommendations with total space requirements that do not exceed the specified limit. Use the
Tuning Options section to specify options that customize the recommendations made by the advisor.
The Prioritize Tuning of SQL Statements by drop-down list allows you to prioritize by Optimizer
Cost, Buffer Gets, CPU Time, Disk Reads, Elapsed Time, and Execution Count. Use the Default
Storage Locations section to override the defaults defined for schema and tablespace locations. By
default, indexes are placed in the schema and tablespace of the table they reference. Materialized
views are placed in the schema and tablespace of the user who executed one of the queries that
contributed to the materialized view recommendation.
Note: Oracle highly recommends that you specify the default schema and tablespaces for
materialized views.

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


SQL Access Advisor: Schedule and Review

9 - 29 Copyright 2007, Oracle. All rights reserved.

SQL Access Advisor: Schedule and Review


You can then schedule and submit your new analysis by specifying various parameters to the
scheduler. The possible options are shown in the screenshots in the slide.

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


SQL Access Advisor: Results

9 - 30 Copyright 2007, Oracle. All rights reserved.

SQL Access Advisor: Results


From the Advisor Central page, you can retrieve the task details for your analysis. By selecting the
task name in the Results section of the Advisor Central page, you can access the Results for Task
Summary page from where you can see an overview of the Access Advisor findings. The page shows
you charts and statistics that provide overall workload performance and potential for improving
query execution time for the recommendations. You can use the page to show statement counts and
recommendation action counts.

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


SQL Access Advisor: Results

9 - 31 Copyright 2007, Oracle. All rights reserved.

SQL Access Advisor: Results (continued)


To see other aspects of the results for the Access Advisor task, choose one of the three other tabs on
the page, Recommendations, SQL Statements, or Details.
On the Recommendation page, you can drill down to each of the recommendations. For each of
them, you can see important information in the Select Recommendations for Implementation table.
You can then select one or more recommendations and schedule their implementation.
If you click the ID for a particular recommendation, you are taken to the Recommendation page that
displays all actions for the specified recommendation and, optionally, to modify the tablespace name
of the statement. When you complete any changes, choose OK to apply the changes. From that page,
you can view the full text of an action by choosing the link in the Action field for the specified
action. You can view the SQL for all actions in the recommendation by clicking Show SQL.

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


SQL Access Advisor: Results

9 - 32 Copyright 2007, Oracle. All rights reserved.

SQL Access Advisor: Recommendation Implementation


Most of these recommendations can be executed on a production system by using simple SQL DDL
statements. For those cases, SQL Advisor produces executable SQL statements. In some instances,
for example, repartitioning existing partitioned tables or existing dependent indexes, simple SQL is
not sufficient. SQL Advisor then generates a script calling external packages such as
DBMS_REDEFINITION in order to enable the user to implement the recommended change.
In the slide example, the SQL Access Advisor makes the recommendation to partition the
SH.CUSTOMERS table on the CUST_CREDIT_LIMIT column. The recommendation uses the
INTERVAL partitioning scheme, and defines the first range of values as being less than 1600.
Interval partitions are partitions based on a numeric range or date-time interval. They extend range
partitioning by instructing the database to create partitions of the specified interval automatically
when data inserted into the table exceeds all of the range partitions.

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


SQL Access Advisor: Results

9 - 33 Copyright 2007, Oracle. All rights reserved.

SQL Access Advisor: Results


The SQL Statements page shows you a chart and a corresponding table that list SQL statements
initially ordered by the largest cost improvement. The top SQL statement is improved the most by
implementing its associated recommendation.

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


SQL Access Advisor: Results

9 - 34 Copyright 2007, Oracle. All rights reserved.

SQL Access Advisor: Results (continued)


The Details page shows you the workload and task options that were used when the task was created.
This page also gives you all journal entries that were logged during the task execution.

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


SQL Access Advisor: PL/SQL Procedure Flow

Step 3
ADD_STS_REF
Step 1
DELETE_STS_REF
CREATE_TASK EXECUTE_TASK
UPDATE_TASK_ATTRIBUTES INTERRUPT/CANCEL_TASK
DELETE_TASK MARK_RECOMMENDATION
QUICK_TUNE UPDATE_REC_ATTRIBUTES
GET_TASK_REPORT
Task-dependent GET_TASK_SCRIPT
SQL
Access Advisor
Advisor-dependent task

Report/Scripts
SET_TASK_PARAMETER
RESET_TASK

Step 2

9 - 35 Copyright 2007, Oracle. All rights reserved.

SQL Access Advisor: PL/SQL Procedure Flow


The graphic shows the typical operational flow of the SQL Access Advisor procedures from the
DBMS_ADVISOR package. You can find a complete description of each of these procedures in the
Oracle Database PL/SQL Packages and Types Reference guide.
Step 1: Create and manage tasks and data. This step uses a SQL Access Advisor task.
Step 2: Prepare tasks for various operations. This step uses SQL Access Advisor parameters.
Step 3: Prepare and analyze data. This step uses SQL Tuning Sets and SQL Access Advisor
tasks. With Oracle Database 11g R1, GET_TASK_REPORT can report back using HTML or
XML in addition to just text.
Note: The DBMS_ADVISOR.QUICK_TUNE procedure is a shortcut that performs all the necessary
operations to analyze a single SQL statement. The operation creates a task for which all parameters
are defaulted. The workload is constituted by the specified statement only. Finally, the task is
executed and the results are saved in the repository. You can also instruct the procedure to implement
the final recommendations.

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


SQL Access Advisor: PL/SQL Example

BEGIN 1
dbms_advisor.create_task(dbms_advisor.sqlaccess_advisor,'MYTASK');
END;

BEGIN
dbms_advisor.set_task_parameter('MYTASK','ANALYSIS_SCOPE','ALL');
2
dbms_advisor.set_task_parameter('MYTASK','MODE','COMPREHENSIVE');
END;

BEGIN 3
dbms_advisor.add_sts_ref('MYTASK','SH','MYSTS');
dbms_advisor.execute_task('MYTASK');
dbms_output.put_line(dbms_advisor.get_task_script('MYTASK'));
END;

9 - 36 Copyright 2007, Oracle. All rights reserved.

SQL Access Advisor: PL/SQL Example


Matching the order shown in the previous slide, the examples in this slide show you a possible SQL
Access Advisor tuning session using PL/SQL code.
The first PL/SQL block creates a new tuning task called MYTASK. This task is uses the SQL Access
Advisor.
The second PL/SQL block sets SQL Access Advisor parameters for MYTASK. In the example, you
set ANALYSIS_SCOPE to ALL, which means you generate recommendations for indexes,
materialized views, and partitions. Then, you set MODE to COMPREHENSIVE to include all SQL
statements that are part of the SQL Tuning Set associated to a future task.
The third PL/SQL block associates a workload to MYTASK. Here, you use an existing SQL Tuning
Set called MYSTS. You can now execute the tuning task. After its execution completes, you can
generate corresponding recommendation scripts as shown in the third example in the slide.
Note: For a complete list of SQL Access Advisor parameters (around 50), refer to the Oracle
Database PL/SQL Packages and Types Reference guide.

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


Summary

In this lesson, you should have learned how to:


Implement the new partitioning methods
Employ data compression
Create a SQL Access Advisor analysis session using
Enterprise Manager
Create a SQL Access Advisor analysis session using
PL/SQL
Set up a SQL Access Advisor analysis to get partition
recommendations

9 - 37 Copyright 2007, Oracle. All rights reserved.

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


Practice 9: Overview

This practice covers the following topics:


Using new partitioning schemes
Using table compression
Getting partitioning advices with SQL Access Advisor

9 - 38 Copyright 2007, Oracle. All rights reserved.

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


Using RMAN Enhancements

Copyright 2007, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to:


Describe the new and enhanced RMAN features in
Oracle Database 11g
Configure archivelog deletion policies
Duplicate active databases by using the Oracle network
(without backups)
Back up large files in multiple sections
Create archival backups for long-term storage
Manage the recovery catalogfor example, merge
multiple catalog versions
Describe the use of virtual private catalogs

10 - 2 Copyright 2007, Oracle. All rights reserved.

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


RMAN: New Features

Improved performance by:


Fast incremental backups on physical standby
Improved block media recovery

Target
Data files database Image copies

Backup pieces
Change
Backup data
tracking
file
Flash Recovery Area

Auxiliary Recovery Manager (RMAN)


database

10 - 3 Copyright 2007, Oracle. All rights reserved.

New Features of RMAN


Backup and recovery operations are a critical part of securing the availability of information,
when an 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.
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,
then RMAN can use these blocks, thereby speeding up block media recovery.

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


Optimized Backups

Increased speed of compression by using the ZLIB


algorithm
CONFIGURE COMPRESSION ALGORITHM TO ZLIB;
Improved protection by enhanced block corruption
detection

10 - 4 Copyright 2007, Oracle. All rights reserved.

Optimized Backups
Increased Speed of Compression When Preserving Backup Space
You can use the CONFIGURE command to choose between the BZIP2 and ZLIB compression
algorithms for RMAN backups. The new ZLIB backup compression algorithm can be 40%
faster than the previous BZIP2 algorithm. The real-world data warehousing database from one
large pharmaceutical company had a compression ratio 2.0:1 with the BZIP2 algorithm, and
1.68:1 with the ZLIB algorithm. Configure the backup compression algorithm with the
following command (replace alg_name with either BZIP2 or ZLIB):
CONFIGURE COMPRESSION ALGORITHM TO 'alg_name';
Note: For more details, see the Oracle Database Backup and Recovery Reference.
Improved Block Corruption Detection
In addition to the RMAN-detected block corruptions, Oracle Database 11g also records live
block corruptions 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.

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


Optimized Backups

Optimized undo backup for automatically reduced


backup time and storage
Flexibility to use VSS-enabled software
Allows the database to participate in snapshots coordinated by
VSS-compliant backup management tools and storage products
Database automatically recovered upon snapshot restore via
RMAN

10 - 5 Copyright 2007, Oracle. All rights reserved.

Optimized Backups (continued)


Optimized Undo Backup
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.

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


Optimized Backups

Simplified archive log management in a multiple-


component environment
Increased availability by failover of backup to optional
destinations

Target
Data files database Image copies

Backup pieces
Archive X
log files
Redundant Backup data
archive log
files Flash Recovery Area

10 - 6 Copyright 2007, Oracle. All rights reserved.

Optimized Backups (continued)


Simplified Archive Log Management in a Multiple-Component Environment
This 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.

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


RMAN: New Features

The following pages have more details about:


Faster and optimized backup through intrafile parallel
backup and restore
Simplified active database duplication
Simplified archival backups for long-term storage
Simplified information infrastructure by merging
catalogs
Enhanced security by restricting DBA backup catalog
access to owned databases virtual private catalog

10 - 7 Copyright 2007, Oracle. All rights reserved.

New Features of RMAN


Intrafile Parallel Backup and Restore for Very Large Files
Backups of a single large data file can now use multiple parallel server processes and channels
to efficiently distribute the workload. The use of multiple sections improves the performance of
backups.
Simplified Active Database Duplication
You can use the network-aware DUPLICATE command to create a duplicate or a standby
database over the network without a need for preexisting database backups. The ease-of-use is
especially apparent through the Enterprise Manager GUI.
Archival Backups for Long-Term Storage
Long-term backups, created with the KEEP option, no longer require all archived logs to be
retained, when the backup is online. Instead, archive logs needed to recover the specified data
files to a consistent point in time are backed up (along with specified data files and a control
file). This functionality reduces archive log backup storage needed for online, long-term KEEP
backups, and simplifies the command by using a single format string for all the files needed to
restore and recover the backup.

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


New Features of RMAN (continued)
Simplified Information Infrastructure by Merging RMAN Catalogs
The new IMPORT CATALOG command allows one catalog schema to be merged into another,
either the whole schema or just the metadata for specific databases in the catalog. This simplifies
catalog management for you by allowing separate catalog schemas, created in different versions,
to be merged into a single catalog schema.
Restricting DBA Backup Catalog Access to Owned Databases
The owner of a recovery catalog can grant or revoke access to a subset of the catalog to database
users. This subset is called a virtual private catalog.

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


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

10 - 9 Copyright 2007, Oracle. All rights reserved.

Parallel Backup and Restore for Very Large Files


Oracle data files can be up to 128 TB in size. In prior versions, the smallest unit of RMAN
backup was 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.
In Enterprise Manager select Availability > Backup Settings > Backup Set (tabbed page).
Oracle Database 11g: New Features for Administrators 10 - 9
Using RMAN Multisection Backups

The BACKUP and VALIDATE DATAFILE commands option:

SECTION SIZE <integer> [M | K | G]

Channel 1
Section 1

Channel 2
Section 2

Channel 3
Section 3
Channel 4
Section 4
One large data file

10 - 10 Copyright 2007, Oracle. All rights reserved.

Using RMAN Multisection Backups


The BACKUP and VALIDATE DATAFILE commands accept a new option:
SECTION SIZE <integer> [M | K | 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.

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


Duplicating a Database

With network (no backups required)


Including customized SPFILE
Via Enterprise Manager or RMAN command line

Destination or
AUXILIARY database
TCP/IP

Active source database

10 - 11 Copyright 2007, Oracle. All rights reserved.

Duplicating a Database
Prior to Oracle Database 11g, you could create a duplicate database with RMAN for testing or
for standby. 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 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.

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


Active Database Duplication:
Selecting the Source

10 - 12 Copyright 2007, Oracle. All rights reserved.

Active Database Duplication


Usage Notes for Active Database Duplication
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.

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


Selecting the Destination

10 - 13 Copyright 2007, Oracle. All rights reserved.

Selecting the Destination


Usage Notes for Active Database Duplication
Password files are copied to the destination. The destination must have the same SYS user
password as the source. In other words, at the beginning of the active database duplication
process, both databases (source and destination) must have password files.
When creating a standby database, the password file from the primary database overwrites the
current (temporary) password file on the standby database. When you use the command line and
do not duplicate for a standby database, then you need to use the PASSWORD clause (with the
FROM ACTIVE DATABASE clause of the RMAN DUPLICATE command).

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


Customizing Destination Options

10 - 14 Copyright 2007, Oracle. All rights reserved.

Customizing Destination Options


Prior to Oracle Database 11g, the SPFILE was not copied, because it requires alterations
appropriate for the destination environment. You had to copy the SPFILE into the new location,
edit it, and specify it when starting the instance in NOMOUNT mode or on the RMAN command
line to be used before opening the newly copied database.
With Oracle Database 11g, you provide your list of parameters and desired values and the
system sets them. The most obvious parameters are those whose value contains a directory
specification. All parameter values that match your choice (with the exception of the
DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT parameters) are placed.
Note the case-sensitivity of parameters: The case must match for
PARAMETER_VALUE_CONVERT. With the FILE_NAME_CONVERT parameters, pattern
matching is operating system specific.
This functionality is equivalent to pausing the database duplication after restoring the SPFILE
and issuing ALTER SYSTEM SET commands to modify the parameter file (before the instance
is mounted).
The example in the slide shows how to clone a database on the same host and in the same Oracle
Home, with the use of different top-level disk locations. The source directories are under u01,
the destination under u02: You need to confirm your choice.

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


Choosing Database Configuration

10 - 15 Copyright 2007, Oracle. All rights reserved.

Choosing Database Configuration


Note how the information you enter is used for the new database.

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


Scheduling Job Execution

10 - 16 Copyright 2007, Oracle. All rights reserved.

Scheduling Job Execution


Following the steps of the wizard, you can now schedule the job, so that it becomes active
according to your specifications.

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


Reviewing the Job

10 - 17 Copyright 2007, Oracle. All rights reserved.

Reviewing the Job


Scroll down to review more details and submit the job. Note that the ORCL database will create
the DBTEST database on the same host in the /u02 directory structure.

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


Database Duplication: Job Run

10 - 18 Copyright 2007, Oracle. All rights reserved.

Database Duplication: Job Run


The example of the Job Run page shows the following steps:
1. Source Preparation
2. Create Control File
3. Destination Directories Creation
4. Copy Initialization and Password Files
* Skip Copy or Transfer Controlfile
5. Destination Preparation
6. Duplicate Database
* Skip Crating Standby Controlfile
* Skip Switching Clone Type
7. Recover Database
8. Add Temporary Files
9. Check Database and Run Post Cloning Scripts
10. Add EM Target
11. Cleanup Source Temporary Directory

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


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'
SET LOG_FILE_NAME_CONVERT = '/u01','/u02'
DB_FILE_NAME_CONVERT = '/u01','/u02';

10 - 19 Copyright 2007, Oracle. All rights reserved.

The RMAN DUPLICATE Command


The example assumes that you have previously connected to both the source and the destination
instances, 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 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
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.

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


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"
SET LOG_FILE_NAME_CONVERT = '/u01','/u02'
DB_FILE_NAME_CONVERT = '/u01','/u02';

10 - 20 Copyright 2007, Oracle. All rights reserved.

Duplicating a Standby Database


The example in the slide assumes that you are connected to the target and auxiliary instances
and that the 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.

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


Creating Archival Backups with EM

10 - 21 Copyright 2007, Oracle. All rights reserved.

Creating Archival Backups with EM


If you have business requirements to keep records for a long time, you can use RMAN to create
a self-contained archival backup of the database or tablespaces. RMAN does not apply the
regular retention policies to this backup. Place your archival backup in a different long-term
storage area, other than in the Flash Recovery Area.
To keep a backup for a long time, perform the following steps in Enterprise Manager:
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.
Backups created with the KEEP option include the SPFILE, control files, and archive redo log
files required to restore this backup. This backup is a snapshot of the database at a point in time,
and can be used to restore the database to another host.

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


Creating Archival Backups with RMAN

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]

List all restore points, known to the RMAN repository:


LIST RESTORE POINT ALL;
Display a specific restore point:
LIST RESTORE POINT 'rsname';

10 - 22 Copyright 2007, Oracle. All rights reserved.

Creating Archival Backups with RMAN


Prior to Oracle Database 11g, if you needed to preserve an online backup for a specified amount
of time, 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), and the relevant autobackup files. All these files must go to the same media family (or
group of tapes) and have the same KEEP attributes.
Oracle Database 11g: New Features for Administrators 10 - 22
Managing Archival Database Backups

1. Archiving a database backup:


CONNECT TARGET /
CONNECT CATALOG rman/rman@catdb
CHANGE BACKUP TAG 'consistent_db_bkup'
KEEP FOREVER;

2. Changing the status of a database copy:


CHANGE COPY OF DATABASE CONTROLFILE NOKEEP;

10 - 23 Copyright 2007, Oracle. All rights reserved.

Managing Archival Database Backups


The CHANGE command changes the exemption status of a backup or copy in relation to the
configured 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.

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


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.
4. If needed, catalog any older backups.
5. If needed, create virtual recovery catalogs for specific
users.
6. Protect the recovery catalog.

10 - 24 Copyright 2007, Oracle. All rights reserved.

Managing Recovery Catalogs


The basic workflow of managing recovery catalogs is not new. However, it has been enhanced
by two 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.

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


Managing Recovery Catalogs (continued)
What You Already Know and What Is New
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
grant or revoke restricted access to the catalog to other database users. All metadata is stored in
the base catalog schema.
Each restricted user has full read-write access to his or her own metadata, which is called a
virtual private catalog.
The recovery catalog obtains crucial RMAN metadata from the control file of each registered
target database. The resynchronization of the recovery catalog ensures that the metadata that
RMAN obtains from the control files is current.
You can use a stored script as an alternative to a command file for managing frequently used
sequences of RMAN commands. The script is stored in the recovery catalog rather than on the
file system. A local stored script is associated with the target database to which RMAN is
connected when the script is created, and can be executed only when you are connected to this
target database. A global stored script can be run against any database registered in the recovery
catalog.
You can use a recovery catalog in an environment in which you use or have used different
versions of the 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.

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


Managing Catalogs: Using EM

2 3

10 - 26 Copyright 2007, Oracle. All rights reserved.

Managing Catalogs: Using EM


In Enterprise Manager, select Availability > Recovery Catalog Settings and then the activity you
want to perform.

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


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;
4. Importing metadata from multiple catalogs:
IMPORT CATALOG cat102/rman@srcdb;
IMPORT CATALOG cat101/rman@srcdb;
IMPORT CATALOG cat92/rman@srcdb NO UNREGISTER;

10 - 27 Copyright 2007, Oracle. All rights reserved.

The IMPORT CATALOG Command


With the IMPORT CATALOG command, you can import the metadata from one recovery
catalog schema 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.
1. RMAN must be connected to the destination recovery catalogfor example, the cat111
schemawhich is the catalog into which you want to import catalog data. This is the first
step in all examples given in the slide.
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.

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


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 Examples (continued)
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
RMAN to import the databases with the DBID 1423241 and 1423242, and unregister
them in the source catalog.
4. The srcdb database contains three different recovery catalogs. RMAN imports metadata
for all database IDs (registered in these catalogs) into the cat111 schema in the destdb
database. All imported target databases are unregistered from their source catalogs except
for the databases registered in the cat92 schema.
Additional Usage Details
Ensure that no target database is registered in both the source catalog schema and the
destination catalog schema. If a target database is registered in both schemas, then
unregister this database from the source catalog and retry the import.
If the operation fails in the middle of the import, then the import is rolled back. There is
never a state of partial import.
When stored scripts in the source and destination catalog schemas have name conflicts,
RMAN renames the stored script of the source catalog schema.

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


10 - 29 Copyright 2007, Oracle. All rights reserved.

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


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. Grant REGISTER to the VPC owner, or:


RMAN> CONNECT CATALOG catowner/oracle@catdb;
RMAN> GRANT REGISTER DATABASE TO vpcowner;

3b. Grant CATALOG FOR DATABASE to the VPC owner:


RMAN>GRANT CATALOG FOR DATABASE db10g TO vpcowner

10 - 30 Copyright 2007, Oracle. All rights reserved.

Using RMAN Virtual Private Catalogs


You create virtual private RMAN catalogs for groups of databases and users.
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 or grant REGISTER to the VPC owner. The GRANT CATALOG command is:
GRANT CATALOG FOR DATABASE prod1, prod2 TO vpcowner;
The GRANT REGISTER command is:
GRANT REGISTER DATABASE TO vpcowner;
The virtual catalog owner can then connect to the catalog for a particular target or register a
target database. After the VPC is configured, the VPC owner uses it just like a standard base
catalog.

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


Using RMAN Virtual Private Catalogs

4a. Create a virtual catalog for 11g clients, or:


RMAN> CONNECT CATALOG vpcowner/oracle@catdb;
RMAN> CREATE VIRTUAL CATALOG;

4b. Create a virtual catalog for pre-11g clients:


SQL> CONNECT vpcowner/oracle@catdb
SQL> exec catowner.dbms_rcvcat.create_virtual_catalog;

5. Register a new database in the catalog:


RMAN> CONNECT TARGET / CATALOG vpcowner/oracle@catdb;
RMAN> REGISTER DATABASE;

6. Use the virtual catalog:


RMAN> CONNECT TARGET / CATALOG vpcowner/oracle@catdb;
RMAN> BACKUP DATABASE;

10 - 31 Copyright 2007, Oracle. All rights reserved.

Using RMAN Virtual Private Catalogs (continued)


4. Create a virtual private catalog.
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 have been granted. For most
RMAN operations, you additionally need the SYSDBA or SYSOPER privileges on the target
database.

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


Summary

In this lesson, you should have learned how to:


Describe the new and enhanced RMAN features in
Oracle Database 11g
Configure archivelog deletion policies
Duplicate active databases by using the Oracle network
(without backups)
Back up large files in multiple sections
Create archival backups for long-term storage
Manage recovery catalogfor example, merge multiple
catalog versions
Describe the use of virtual private catalogs

10 - 32 Copyright 2007, Oracle. All rights reserved.

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


Practice 10: Overview
Using RMAN Enhancements

This practice covers the following topics:


Duplicating an active database
Merging catalogs

10 - 33 Copyright 2007, Oracle. All rights reserved.

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

Das könnte Ihnen auch gefallen