11g New Features For Administrators Student Guide-3

Using EM to Manage ASM Users
2 - 17 Copyright © 2007, Oracle. All rights reserved.
Using EM to Manage ASM Users

EM allows 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.
You only have this functionality when connected as the SYSASM user. It is hidden if you connect
as SYSDBA or SYSOPER users.
When you click the Create button, the Create User page is displayed.
When you click the Edit button the Edit User page is displayed.
By clicking the Delete button, you can delete the created users.
Note: Oracle Database 11g adds the SYSASM role to the ASM instance login page.
Oracle Database 11g: New Features for Administrators 2 - 17

ASM Disk Group Compatibility
• Compatibility of each disk group is separately

controllable:
– ASM compatibility controls ASM metadata on disk
structure
– RDBMS compatibility controls minimum client level
– Useful with heterogeneous environments
• Setting disk group compatibility is irreversible
DB ASM Disk ASM

instance Group instance
COMPATIBLE >= COMPATIBLE.RDBMS

<=
COMPATIBLE.ASM <= COMPATIBLE
ASM Disk Group Compatibility

There are two kinds of compatibility applicable to ASM disk groups; dealing with the persistent
data structures that describe a disk group, and the capabilities of the clients (consumers of disk
groups). These attributes are called ASM compatibility and RDBMS compatibility respectively.
The compatibility of each disk group is independently controllable. This is required to enable
heterogeneous environments with disk groups from both Oracle Database 10g and Oracle
Database 11g. 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 dictates the format
of messages that are exchanged between the ASM and database (RDBMS) instances. An
ASM instance has the capability to support 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, software version of the database and the RDBMS compatibility setting of a disk
group determine if a database instance can mount a given disk group.

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 only concerned with the format of the ASM metadata. The format of
the file contents is up to 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 disk
group can only be managed 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 only needs to be advanced when there is 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 or ALTER DISKGROUP commands.
Note: In addition to the 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 10g (disk online/offline, variable extents,
etc).

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 database version Format of ASM metadata structures on disk
disk_repair_time A 0 M to 232 D Length time before removing a disk once

OFFLINE
template.tname. A UNPROTECT|MIRROR|HIGH Redundancy of specified template
redundancy
template.tname. A COARSE|FINE Stripping attribute of specified template
stripe
CREATE DISKGROUP DATA NORMAL REDUNDANCY

DISK '/dev/raw/raw1','/dev/raw/raw2'
ATTRIBUTE 'compatible.asm'='11.1';
ASM Disk Group Attributes

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

Using EM to Edit Disk Group Attributes
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 disk
group advanced attributes page. The disk_repair_time attribute is added to the edit disk
group advanced attributes page only.
Note: For pre-11g ASM instances, the default ASM compatibility and client compatibility is 10.1.
For 11g ASM instances, the default ASM compatibility is 11.1 and database compatibility is 10.1

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;
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 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, or
FILE. Those clauses have been deprecated as they are no longer needed. In the current release, the
CHECK keyword performs the following operations:
• Check 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 consistently, equivalent to
CHECK FILE in previous releases.
• Checks that the alias metadata directory and 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 lets you instruct ASM whether or not to attempt to repair any
errors found during the consistency check. The default is REPAIR. The NOREPAIR setting is
useful if 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 does slow down the entire check disk
group operation.

Restricted Mount Disk Group For Fast Rebalance
• Disk group can only be mounted on a single instance

• No database clients or other ASM instance can get
access
• Rebalance can proceed without locking overhead
1 ALTER DISKGROUP data DISMOUNT;
2 ALTER DISKGROUP data MOUNT RESTRICT;
3 Maintenance task: Add/Remove disks …
4 ALTER DISKGROUP data DISMOUNT;
5 ALTER DISKGROUP data MOUNT;
Restricted Mount Disk Group For Fast Rebalance

A new mount mode to mount a disk group in Oracle Database 11g is called RESTRICTED. When
a disk group is mounted in RESTRICTED mode, clients cannot access the files in a disk group.
When ASM instance knows that there is no clients, it can improve 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 and
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 any external interaction.
At the end of the maintenance cycle you have to explicitly dismount the disk group and remount
it in normal mode.
The ALTER DISKROUP diskgroupname MOUNT command is extended to allow for ASM to
mount the diskgroup in restricted mode. An example is shown on the slide.
When you use RESTRICTED option to startup a ASM instance, all the disk groups defined in
ASM_DISKGROUPS parameter are mounted in RESTRICTED mode.
Note: The restricted mode is not allowed if the cluster is in rolling migration.

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 available
ALTER DISKGROUP data MOUNT FORCE|[NOFORCE];
Mount Force Disk Group

This feature alters the behavior of ASM when mounting an incomplete disk group. With Oracle
Database 10g as long as there are enough failure groups to mount a disk group, the mount
operation succeeds, even when there are potentially missing or damaged failure groups. This
behavior has the potential to automatically drop ASM disks requiring adding them back again
later when repaired, 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 like ASM_DISKSTRING set incorrectly, or
connectivity issues before trying the mount again.
However disk groups mounted with 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 actions before
DISK_REPAIR_TIME expires to restore those devices. Failing to online those devices would
result in the disks being expelled from the disk group and costly rebalance needed to restore
redundancy for all the files in the disk group. Also, if one or more devices are off lined as a result
of MOUNT FORCE then some or all files will not be properly protected until the redundancy is
restored in the disk group via rebalance.
So, mount with FORCE is useful in cases where you know a priori that some of the disks
belonging to a disk group are unavailable. The disk group mount will succeed if ASM finds
enough disks to form a quorum.

Mount Force Disk Group (Continued)
Mount with NOFORCE is the default option of mount when none is specified. In the NOFORCE
mode, all the 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 will also result in an error. There is
one special case in a cluster: if an ASM instance is not the first to mount the disk group, then
MOUNT FORCE fails with an error if disks are determined to be inaccessible locally but
accessible by another instance.

Drop Force Disk Group
• Allows users to drop disk groups that cannot be

mounted
• Fails if disk group is mounted anywhere
DROP DISKGROUP data FORCE INCLUDING CONTENTS;
Drop Force Disk Group

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, then the statement
fails. If the disk group is in a different cluster, then the system further checks to determine
whether the disk group is mounted by any instance in the other cluster. If it is mounted elsewhere,
then the statement fails. However, this latter check is not as definitive as the checks for disk
groups in the same cluster. Therefore, use this clause with caution.
Note: When executing the DROP DISKGROUP command with the FORCE option, you must also
specify the INCLUDING CONTENTS clause.

ASMCMD Extensions
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
ASMCMD Extensions
• ASMCMD is extended to include ASM metadata backup and restore functionality. This
provides the ability to recreate a pre-existing ASM disk group with exact same template and
alias directory structure. Currently if an ASM disk group is lost, it is possible to restore the
lost files using RMAN but you have to manually recreate ASM disk group and any required
user directories/templates. There is no way to backup and restore ASM metadata. ASM
metadata backup and restore (AMBR) works in two modes. In backup mode it parses ASM
fixed tables and views to gather information about existing disks and failure group
configurations, template and alias directory structure. 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 possibility to control AMBR
behavior in restore mode to do a full, nodg, or newdg restore. The difference between the
three sub-modes is to whether you want to include the disk group creation or not, and change
its characteristics.
• The lsdsk command lists ASM disk information. This command can run in two modes:
connected and non-connected. In connected mode, ASMCMD uses the V$ and GV$ views to
retrieve disk information. In non-connected mode, ASMCMD scans disk headers to retrieve
disk information, using an ASM disk string to restrict the discovery set. The connected mode
is always attempted, first.

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 write to it and by relocating it if the
copy failed to produce a good read. This whole process happens automatically only on blocks
that are read. It is possible that some blocks and extents on an ASM disk group are seldom
read. One prime example is the secondary extents. The ASMCMD repair command is design
to trigger a read on these extents, so the resulting failure in I/O can start the automatic block
repair process. One can use the ASMCMD repair interface if the storage array returns an
error on a physical block, then the ASMCMD repair can initiate a read on that block to
trigger the repair.
Note: For more information about the syntax for each of these commands, refer to the Oracle
Database Storage Administrator's Guide 11g Release 1 (11.1)

ASMCMD Extension Examples
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 using RMAN
ASMCMD Extension Examples

This example describes how to backup ASM metadata using the md_backup command, and how
to restore them using the md_restore command.
The first statement specifies the –b option and the –g option of the command. This is to define 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 above example.
At step two, it is assumed that there is a problem on the DATA disk group, and as a result it gets
dropped.
Before you can restore the database files it contained, you have to restore the disk group itself.
At step three, you initiate the disk group recreation as well as restoring its metadata using the
md_restore command. Here, you specify the name of the backup file generated at step one, as well
as the name of the disk group you want to restore, and also the type of restore you want to do.
Here a full restore of the disk group is done because it no longer exist.
Once the disk group is recreated, you can restore its database files using RMAN for example.

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

• Setup ASM fast mirror resynch
• Use ASM preferred mirror read
• Setup ASM disk group attributes
• Use SYSASM role
• Use various new manageability options for CHECK,
MOUNT, and DROP commands
• Use the mb_backup, md_restore, and repair ASMCMD
extensions

SQL Performance Analyzer
Copyright © 2007, Oracle. All rights reserved.

Objectives
After completing this lesson, you should be able to:

• Understand what is SQL Performance Analyzer
• Use SQL Performance Analyzer
3-2 Copyright © 2007, Oracle. All rights reserved.

SQL Performance Analyzer Overview
New feature in 11g

Targeted users: DBAs, QA and Application Developers
Helps predict the impact of system changes on SQL
workload response time
Builds different versions of SQL workload performance
(i.e., SQL execution plans and execution statistics)
Executes SQL serially: concurrency is not respected
Analyzes performance differences
Offers fine-grained performance analysis on individual
SQL
Integrated with SQL Tuning Advisor to tune
regressions
SQL Performance Analyzer Overview

Oracle Database 11g introduces the SQL Performance Analyzer feature. SQL Performance
Analyzer helps you forecast the impact of a potential change on the performance of a SQL query
workload. This enables you to make changes in a test environment to determine if the workload
performance will be improved through a database upgrade for example.

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/hardware changes
SQL Performance Analyzer Use Cases

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

Usage Model (1): Capture SQL Workload
• SQL Tuning Set (STS) used to

store SQL workload. Includes:
– SQL Text
– Bind variables
Cursor cache – Execution plans
Incremental capture
– Execution statistics
• Incremental capture used to
Database Instance
populate STS from cursor cache
over a time period
• SQL tuning set’s filtering and
ranking capabilities filters out
undesirable SQL
Production
Database

Usage Model (2): Transport to a Test System
Cursor cache
Database Instance Database Instance
Production Test
Database Database
• Copy SQL tuning set to staging table (“pack”)

• Transport staging table to test system (datapump, db link, etc.)
• Copy SQL tuning set from staging table (“unpack”)

Usage Model (3): Build Before Change Performance
• Before change SQL performance

version is the SQL workload Test/Execute
performance baseline
• SQL Performance = execution plans
+ execution statistics
• Test-Execute SQL in SQL tuning Before
set: changes
Database Instance
– produce execution plans and
statistics
– execute SQL serially
(no concurrency)
– every SQL is executed only once
– skip DDL/DML effects
• Explain plan SQL in SQL tuning set
Test
to generate SQL plans only Database

Usage Model (4): Build After Change Performance
• Manually implement the planned

change:
– Database upgrade
– Implementation of tuning
recommendations
– Schema changes
– Statistics gathering After
– Database parameter changes changes Database Instance
After changes
– OS/hardware changes, etc. implemented
• Re-execute SQL after change:
– Test-Execute SQL in SQL tuning
set to generate SQL execution
plans and statistics
– Explain plan SQL in SQL tuning set
to generate SQL plans Test
Database

Usage Model (5): Compare and Analyze Performance
• Rely on user-specified metric to
SQL Tuning Advisor
compare SQL performance:
elapsed_time, buffer_gets,
disk_reads, ...
• Calculate change impact on
individual SQLs and SQL workload: improvement regression
– Overal impact on workload
Compare
– SQL Net 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 to run SQL tuning
advisor to tune regressed SQLs
Test
• Analysis results can be used to seed Database
SQL Plan Management baselines

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 3 and 5
7. Tune regressed SQL
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 (STS) or the Automatic
Workload Repository (AWR) to capture the information to transport. As AWR essentially
captures high-load SQLs, you should consider modifying the default AWR snapshot settings and
captured Top SQL to ensure AWR captures the maximum number of SQL statements. This would
ensure a 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 needed to assess the impact a future change may 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: Execution plans, generated by explain plan for example.
• Execution statistics: Includes elapsed time, buffer gets, disk reads, rows processed for
example.
4. Make a change: Once you have the before version data, you can then implement your planned
change and start viewing the impact on performance.

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 at step 3.
6. Compare and analyze SQL Performance: Once you have both versions of the SQL workload
performance data, you can now perform the performance analysis 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. From here, you can use any of
the database tools to tune the system. For example, you could use the SQL Tuning Advisor or
Access Advisor against the identified statements, and implement those recommendations. Or
alternatively, you can seed SPM with plans captured at step 3 to guarantee the plans remain the
same. Once you implement any tuning action you should then repeat the process to create a new
“after version” and analyze the performance differences to ensure the new performance is
acceptable.

Enterprise Manager: Capturing the SQL Workload
Creating a SQL Tuning Set:
Enterprise Manager: Capturing the SQL Workload

Enterprise Manager (EM) launches a wizard allowing you to create a new SQL Tuning Set. This
wizard allows you to select a load method and a data source, to specify filter conditions for
selecting SQL statements that are to be loaded into the new SQL Tuning Set, and to schedule it as
a job to be executed at a particular time.
You access the SQL Tuning Sets page from the Performance tab in Database Control Oracle
Database 11g. From this page you can create a STS. The workload 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
the production system. The performance data is computed later on the test system by the compute
SQL performance processes.
The SQL Performance Analyzer tracks the SQL performance of the same STS before and after a
change is made to the database.

Capturing the SQL Workload

The Create STS Tuning Set wizard provided in EM in Oracle Database 11g guides you through
the capturing of SQL statements.
From the Options you define the attributes needed to create a new SQL Tuning Set. You can
decide whether to collect any SQL statements at this time, or not. If you choose not to, the wizard
jumps to the Review page.


You choose to either incrementally collect SQL workload over a period of time, or to collect SQL
statements one time only.
You can choose to capture the SQL statements from the following sources:
• Cursor Cache
• AWR Snapshots
• AWR Baselines
• User-defined Workload: A user-defined table that stores SQL statements. Must have
sql_text and parsing_schema_name columns. Ideally, it should also have columns
that contain SQL statistics.
EM provides the following support for SQL Performance Analyzer:
• View previously captured workloads and their details.
• Capture the SQL.
• Export a workload.
• Import a workload.
• Compute SQL performance.
• Manage SQL performance data.
• Report analysis result.
• Run SQL Advisor to tune regressed SQL statements.
• View previously executed SQL Performance Analyzer tasks and their results.


You are then able to create filters against the type of SQL conditions for capture. In the above
example the schema APPS, SELECT SQL statements and APPS_DEMO module are selected for
capture from the cursor cache.
The actual filter options will depend on the selected load methods.
The final stage in the wizard allows you to select a job schedule time (IMMEDIATE, LATER),
review your job options and submit the job.

Exporting the SQL Workload
Exporting the SQL Workload

From this page you can choose to export the selected STS for transport to the test system. You can
also drill down and see the SQL statements contained within the selected STS.
You also use this page to import a STS from a previously exported file. This is how you would
load a STS on the test system for comparison purposes.

Creating a SQL Performance Analyzer Task
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 applies to both EM Database Control and EM
Grid Control.
You access SQL Performance Analyzer from the Software and Support tab of Database Control,
or Database Instance > Advisor Central > SQL Performance Analyzer.
This takes you to the screen to create the necessary tasks to capture the before, after, and tuned
performance data.

SQL Performance Analyzer Task Flow

Once you have selected the Create SQL Replay Task button you are presented with a wizard to
walk you through the steps of performing a SQL Performance Analyzer task. Each of these steps
is sequential and you cannot alter the settings after the steps completion. The steps involved are as
follows:
1. Select SQL Tuning Set
- This phase allows you to select the desired imported STS.
2. Establish Initial Environment
- Depending on the change you are testing, you need to establish the initial environment
on the current system. This could involve changing initialization parameters for
example.
3. Collect SQL Performance Before Change
- This step involves running the captured workload under the initial environment while
capturing the performance statistics.
4. Make Change
- Here you are asked to confirm that you have made the necessary SQL changes that you
are wishing to test with the supplied SQL workload.
5. Collect SQL Performance After Change
- You now rerun the STS against the post-change environment, collecting again the
performance statistics.
6. Compare SQL Performance Before and After Change
- It is at this stage that actual comparison statistics are generated.


You select the desired metrics you wish to base your comparison on and the schedule to submit
the job (IMMEDIATELY, LATER). Once this step has completed successfully, you click the
View Analyze Result button to view the results of the comparison.

Viewing Analysis Results

The View Analyze Result button displays the above charts. Here you can see the before and after
graphical representation of the SQL workload for the selected comparison metric. You can drill
down on the improved, regressed and overall impact SQL statements for further illustration. From
many of these screens you can choose to run the SQL Tuning Advisor.

Improved SQL Statements

When you click the SQL ID associated with the calculated improved statement you are presented
with a more detailed illustration of the SQL.

Improved SQL Statements

The detailed page gives you execution statistics for the selected SQL statement. Using the
scrollable windows at the bottom of the screen, you can view the plan table of the SQL statement
before and after the proposed change. You can also view the actual SQL text.

Regressed SQL Statements

On the regressed SQL page, you have additional information messages on the problem, symptom,
and informational findings. Throughout these screens you can choose to run the SQL Tuning
Advisor to make tuning recommendations.

Viewing Tuning Results

When you click the Schedule SQL Tuning Advisor button, you complete the job name and
optional job details and submit the job as required (IMMEDIATE, LATER).
On successful job completion you go to the Advisor Central page and drill down to view the
recommendations of the run.


You can view the detail of the suggested statement improvements by selecting a specific type.
The improvement identified by the SQL Tuning Advisor as having the highest benefit
(percentage) is presented at the top of the list.
You are recommended to implement only one change at a time and repeat the analysis process,
capturing ‘after tuning’ performance data and re-analyzing the recommendations against the ‘after
change’ performance data.

SQL Performance Analyzer: PL/SQL Packages
• PL/SQL package:
– DBMS_SQLTUNE
• Main APIs:
– CREATE_TUNING_TASK:Creates an advisor task
– EXECUTE_TUNING_TASK:Executes a previously created
tuning task
– REPORT_TUNING_TASK:Displays the results of a tuning
task

SQL Performance Analyzer: Data Dictionary
Views
• Modified views in Oracle Database 11g:

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

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

impact analysis of a system environment change.
DBA{USER}_ADVISOR_EXECUTIONS:Lists metadata information for a task execution. SQL
Performance Analyzer analyzer creates a minimum three executions to perform a change impact
analysis on a SQL workload. A first execution that collects performance data for the before
change version of the workload, a second execution of 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.

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

• Understand what is SQL Performance Analyzer
• Use SQL Performance Analyzer

Practice 3: Overview
This practice covers the following topics:

• Capture SQL Tuning Sets
• Migrate STS from Oracle Database 10g to Oracle
Database 11g
• Use SQL Performance Analyzer in an upgrade scenario
• Use SQL Performance Analyzer in a change scenario

SQL Plan Manageability
Copyright © 2007, Oracle. All rights reserved.

Objectives
After completing this lesson, you should be able to:

• Setup SQL Plan Manageability
• Setup various SQL Plan Manageability scenarios

SQL Plan Management Overview
• SQL Plan Management is automatic 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
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, as well as SQL profile creation.
Various plan control techniques like stored outlines and SQL profiles have been introduced in past
Oracle versions to address the 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 allows 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 only integrate a SQL plan
baseline if it has been proven that doing so will not generate performance regression. So, during
execution of a SQL statement, only a SQL plan 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 possible scenarios are studied 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. Additionally, it saves the DBA time spent in
identifying and analyzing SQL performance regressions and finding workable solutions.

SQL Plan Manageability Overview
You can play the following mini lesson to better

understand SQL Plan Manageability:
SQL Plan Manageability Overview (See URL in notes)
ASM Fast Disk Resync Overview

To better understand the following slides, you can spend some time playing the following mini
lesson at:
http://stcontent.oracle.com/content/dav/oracle/Libraries/ST%20Curriculum/ST%20Curriculum-
Public/Courses/Oracle%20Database%2011g/Oracle%20Database%2011g%20Release%201/11gR
1_Mini_Lessons/11gR1_Beta1_OPM_JFV/11gR1_Beta1_OPM4_viewlet_swf.html

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
SQL Plan Baseline Architecture

SQL Pan Management (SPM) feature introduces necessary infrastructure and services in support
of plan maintenance and performance verification of new plans.
For this, the optimizer maintains a history of plans for individual SQL statements for SQL
statements that are executed more than once. 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. Once a SQL statement is recognized as
repeatable, from then on various plans generated by the optimizer are maintained as a plan history
which contains relevant information used by the optimizer to reproduce an execution plan like
SQL text, outline, bind variables, and compilation environment.
As an alternative or as a 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
brand new plan generated by the optimizer will not be normally used until it has been verified not
to cause a performance regression. Out-of-the-box the plan verification is done as part of
Automatic SQL Tuning that is run as an automated task in a maintenance window.

SQL Plan Baseline Architecture (Continued)
Automatic SQL Tuning task targets only the high-load SQL statements and 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, and therefore, it forms the original plan baseline. Any
new plan subsequently found by the optimizer are part of the plan history but not part of the plan
baseline initially.
The statement log, the 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, such as periodic
purging of unused plans. You can configure the SMB to change plan retention policy and set
space size limit.
Note: With Oracle Database 11g if the database instance is up but SYSAUX tablespace is
OFFLINE then the optimizer will not be able to access SQL management objects and hence this
can impact the performance on some of the SQL workload.

Loading SQL Plan Baseline
optimizer_capture_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 s
Pl GB eline
4
HJ
HJ
DBA
Loading Plan Baseline

You basically have two possibilities to load SQL plan baselines:
On the fly capture
• The first one is to use automatic plan capture by setting the initialization parameter
OPTIMIZER_CAPTURE_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 on the left part of
the graphic where you can see the first generated SQL plan automatically integrated to the
original SQL plan baseline.
Bulk loading
• The second loading mechanism uses the DBMS_SPM package. This package allows 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, that SQL statement
needs to store its SQL plan in the STS. DBMS_SPM allows you to change the status of a
baseline plan from accepted to not accepted and vica versa. It also allows you to export
baseline plans from a staging table which can then be used to load SQL plan baselines on
other databases.

11g New Features For Administrators Student Guide-3

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

11g New Features For Administrators Student Guide-3

Загружено:

Авторское право:

Доступные форматы

Using EM to Manage ASM Users

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

Using EM to Manage ASM Users

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

• Compatibility of each disk group is separately

DB ASM Disk ASM

COMPATIBLE >= COMPATIBLE.RDBMS

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

ASM Disk Group Compatibility

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

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

Name Property Values Description

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

disk_repair_time A 0 M to 232 D Length time before removing a disk once

CREATE DISKGROUP DATA NORMAL REDUNDANCY

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

ASM Disk Group Attributes

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

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

Using EM to Edit Disk Group Attributes

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

• Disk group check syntax is simplified

ALTER DISKGROUP DATA CHECK;

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

Enhanced Disk Group Checks

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

• Disk group can only be mounted on a single instance

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

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

• By default MOUNT is NOFORCE:

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

Mount Force Disk Group

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

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

• Allows users to drop disk groups that cannot be

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

Drop Force Disk Group

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

User created directories

repair $ asmcmd help md_restore nodg

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

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

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

2 Unintentional disk group drop

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

4 Restore disk group files using RMAN

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

ASMCMD Extension Examples

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

In this lesson, you should have learned how to:

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

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

Copyright © 2007, Oracle. All rights reserved.

After completing this lesson, you should be able to:

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

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

New feature in 11g