11g New Features For Administrators Student Guide-5 PDF

Practice 5: Overview
This practice covers the following topics:

• Use Database Replay using Enterprise Manager with
the following scenarios:
– Replay in synchronous mode without changes
– Replay in synchronous mode after changes are applied
– Replay in non-synchronous mode without changes
5 - 39 Copyright © 2007, Oracle. All rights reserved.
Oracle Database 11g: New Features for Administrators 5 - 39

Automatic SQL Tuning
Copyright © 2007, Oracle. All rights reserved.

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

• Setup and modify Automatic SQL Tuning
• Use PL/SQL interface to perform fine tuning
• View and interpret reports generated by Automatic SQL
Tuning
6-2 Copyright © 2007, Oracle. All rights reserved.

Automatic SQL Tuning Overview
You can play the following mini lesson to better

understand Automatic SQL Tuning:
Automatic SQL Tuning 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_Auto_SQL_Tuning_JFV/11gR1_Beta1_Auto_SQL_Tuning_view
let_swf.html

SQL Tuning in Oracle Database 10g
Workload
Accept Profiles
SQL Tuning
Automatic High load Advisor 4
Generate
SQL Profiles
2
ADDM
DBA
3
Run SQL Tuning Advisor
SQL Tuning in Oracle Database 10g

Oracle Database 10g introduced the 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 a SQL statement has not been designed in the most efficient
fashion, as well as the (more common) problem where a SQL 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 on how to speed up SQL performance, but it
leaves the responsibility of implementing recommendations to the user.
In addition to the 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: While 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 them for
tuning.

Automatic SQL Tuning in Oracle Database 11g
AWR
To
p
SQ
L
Workload Auto matic
SQL Tuning
R
ep
or
4
ts
DBA

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 any 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:
1) Based on 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.
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 the SQL Tuning
Advisor, and as a result, SQL Profiles will be created for them if needed. Before making any
decision, the new profile is carefully tested.
4) At any point in time, you can request a report about these automatic tuning activities. You then
have the option to check the tuned SQL statements to validate or remove the automatic SQL
Profiles which were generated.

Summary of Automation in 11g
• Task runs automatically (Autotask Framework)

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

Picking Candidate SQL
AWR
Weekly Daily Hourly Average Exec
Candidate List
1. Pull the top queries from the past week into four buckets:
Top for the past week
Top for any day in the past week
Top in any hour (single snapshot)
Top by average single execution
2. Combine four buckets into one, assigning weights
3. Cap at 150 queries per bucket

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 any 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:
1) Based on 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.
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 the SQL Tuning
Advisor, and as a result, SQL Profiles will be created for them if needed. Before making any
decision, the new profile is carefully tested.
4) At any point in time, you can request a report about these automatic tuning activities. You then
have the option to check the tuned SQL statements to validate or remove the automatic SQL
Profiles which were generated.

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

The Automatic SQL Tuning process takes place during the maintenance window. Furthermore, it
runs as part of a single AUTOTASK job on a single instance to avoid concurrency issues. This is
portrayed in the above graphic for one possible sample scenario:
In this scenario, at some time after the beginning of the maintenance window, AUTOTASK starts
up the Automatic SQL Tuning job. The first thing it does is to generate a list of candidate SQL for
tuning, according to AWR source. Once the list is complete it tunes each statement in order of
importance, one after another, only considering one statement at a time. In this scenario, it first
tunes S1, which has a SQL Profile recommendation (P1) generated for it by the SQL Tuning
Advisor. Once P1 has been successfully tested, it is accepted, and the job moves on to the next
statement, S2.
Note: Widths of boxes in the diagram above do not indicate relative execution times. Tuning and
test execution should be the most expensive processes by far, with all the others completing
relatively quickly.

Automatic Tuning Process
Not considered
Restructure
SQL New
SQL profile
Existing N 3X Y
Accept profile
Indexes profile? benefit?
N
Y
3X N
Ignore new profile
benefit?
Stale
stats
Y
Replace profile
GATHER_STATS_JOB
Automatic Tuning Process

With the list of candidate SQL already built and ordered, the statements are then tuned using the
SQL Tuning Advisor, and any SQL Profiles recommended that improve the performance of the
SQL significantly, are implemented automatically. In Oracle Database 11g, the performance
improvement factor has to be at least 3 before a SQL Profiles is implemented. As we have already
mentioned, the Automatic SQL Tuning process only implements SQL Profile recommendations
automatically. Other recommendations to create new indexes or to refresh stale statistics or to
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 does the following:
1) Tune the statement using the SQL Tuning Advisor. Look for a SQL Profile and if it is found
check if base optimizer statistics are current for it.

Automatic Tuning Process (Continued)
2) If a SQL profile is recommended:
• 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 or not to implement the SQL profile.
It will make its decision according to the flowchart shown above. While the benefit
thresholds here apply to the sum of CPU and IO time, SQL Profiles will not be accepted if
there is a degradation in either statistic. So the requirement is that there is a three times
improvement in the sum of CPU and IO time, with neither statistic becoming worse. This
way the statement will run faster than it would without the profile, even with contention in
CPU or IO.
3) If stale or missing statistics are found, make this information available to
GATHER_STATS_JOB.
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 to something appropriate for their workload.

Focus on SQL Profiles
Auto-testing/implementing is limited to profiles because:

• No lengthy, expensive set-up process
(gathering stats, building an index takes time)
• Private to the current compilation
• No change to user SQL (does not change semantics)
• SQL-level recommendation, can be effectively tested
• Easily reversed by the DBA
Testing is done for regular SQL tune tasks as well!

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
– Disable test-execute to save time
– Max SQL profiles accepted per day / overall
– Task execution expiration period

Automatic SQL Tuning Task
Automatic SQL Tuning Task

As it has already been mentioned, Automatic SQL Tuning is implemented as an automated
maintenance task 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. You can get there from your Database Control Home page by clicking the Server tab, and
once on the Server page, by clicking the Automated Maintenance Tasks link in the Tasks section.
On the Automated Maintenance Tasks page, you can see the predefined tasks. You can then
access each task by clicking on the corresponding link to get more information about the task
itself. This is illustrated on the above slide. When you click on 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.

Automatic SQL Tuning Configuration
Automatic SQL Tuning Configuration

Although Automatic SQL Tuning is enabled by default, you have the possibility to control its
execution from Enterprise Manager. On the Automatic SQL Tuning Result Summary page, you
can click Configure. This takes you to the Auto Task Configuration page from where you can
Disable or Enable Automatic SQL Tuning. 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. From this page, you also have the possibility to edit each Window
to change its characteristics. You can do so by clicking Edit Window Group.
Note: In addition to the above, if you set STATISTICS_LEVEL to BASIC, turn off AWR
snapshots using DBMS_WORKLOAD_REPOSITORY, or if AWR retention is less than seven
days, you also stop Automatic SQL Tuning.

Automatic SQL Tuning Result Summary
Automatic SQL Tuning Result Summary

In addition to give you the possibility to control the Automatic SQL Tuning task, the Automatic
SQL Tuning Result Summary page also contains various summary graphs. A particular example
is given on the slide. The first chart in the Overall Task Statistics 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 dropdown list. In the
above example, All is used. This covers all executions of the task thus far. Users can request it for
any time period over the past month, since that is the amount of time the advisor persists its tuning
history.
On the Breakdown by Finding Type graph, you can clearly see that only SQL profiles can be
implemented, and although a lot more were recommended, not all of them were automatically
implemented for the reasons we already explained. Similarly, recommendations for index
creation, and the other types are not implemented. However, the advisor keeps historical
information about all recommendations in case you want to implement them later.

Automatic SQL Tuning Result Recommendations
Automatic SQL Tuning Result Recommendations

From the Automatic SQL Tuning Result Summary page, you can drilldown to the Automatic SQL
Tuning Result Details page by clicking the View Report button as shown on the previous slide.
From the Automatic SQL Tuning Result Details page you have the possibility to select one
statement and click the View Recommendations button. This takes you to the Recommendations
for SQL ID page for the corresponding statement. On this page, you can look at the new explain
plan, or compare explain plans if the corresponding recommendation was implemented. This is
the case in the example shown on the slide. You also have the possibility to implement manually a
recommendation that was not automatically implemented by Automatic SQL Tuning.

Automatic SQL Tuning Result Details
Automatic SQL Tuning Result Details

On the Automatic SQL Tuning Result Details page you can also see for each automatically tuned
SQL statement various important information: its SQL text and SQL ID, the type of
recommendation that was done by the SQL Tuning Advisor, the verified benefit percentage if the
recommendation was automatically applied, and the date of the recommendation.
From this page, you can either drilldown to the SQL statement itself by clicking on its
corresponding SQL ID link (shown on the slide), or select one of the SQL statement, and click the
View Recommendations button to have more details about the recommendation for that statement.

Automatic SQL Tuning Result Details Drilldown
Automatic SQL Tuning Result Details Drilldown

When you drilldown to a particular SQL statement from the Automatic SQL Tuning Result
Details page, you end up on the SQL Details page of that statement. There, you can find out about
various statistics about the statement, look at its past or current activity, or find out about its
tuning information. This last drilldown possibility is illustrated on the slide. In the example, you
can see that there is currently a profile associated to that statement, and the profile was
automatically created by SYS_AUTO_SQL_TUNING_TASK. From that page, you can manage
this profile by changing its category, delete it, or disable it.

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
Automatic SQL Tuning Fine Tune

You can use the DBMS_SQLTUNE PL/SQL package to control various aspects of the
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 per run
• MAX_AUTO_SQL_PROFILES: Maximum number of automatic SQL Profiles allowed on
the system in total
2) EXECUTE_TUNING_TASK function: used to manually run a new execution of the task in the
foreground (behaves just like it would when 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 using the
DBMS_AUTO_TASK_ADMIN PL/SQL package.

Automatic SQL Tuning Fine Tune (Continued)
You can also access various Automatic SQL Tuning information through the above highlighted
dictionary views:
• DBA_ADVISOR_EXECUTIONS: get data about each execution of the task
• DBA_ADVISOR_SQLSTATS: see the test-execute statistics generated from when we are
testing the SQL Profiles
• DBA_ADVISOR_SQLPLANS: see the plans encountered during test-execute

Getting Reports Using PL/SQL Interface
Getting Reports Using PL/SQL Interface

The above example shows you how to invoke the REPORT_AUTO_TUNING_TASK function to
get a text report related to two executions of the task.
The first command lists executions, and the second gives the summary and general information
about executions.

Automatic SQL Tuning Considerations
• SQL not considered for Automatic SQL Tuning:

– Ad hoc or rarely repeated SQL
– Parallel queries
– Still long-running queries after profiling
– Recursive SQL statements
– DMLs and DDLs
• Above categories can still be manually tuned using
SQL Advisor.
Automatic SQL Tuning Considerations

Automatic SQL Tuning does not seek to solve every SQL performance issue occurring on a
system. It not aim to tune 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 no repeat within a week are not considered as well.
• Parallel queries are not considered for tuning.
• Long-running queries (post-profile): If a query takes too long to run after being SQL profiled,
it will not be practical to test-execute and, therefore, will be ignored by the advisor. Note that
this does not mean 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 still be accepted
because test-execution is still possible. The advisor would execute the old plan just long
enough to determine it is worse than the new one, and then terminate test execution without
waiting for the old plan to finish, thus switching the order of their execution.
• Recursive SQL statements
• DMLS like INSERT SELECT statements, or DDLs like 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 the SQL Tuning Advisor.

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

• Setup and modify Automatic SQL Tuning
• Use PL/SQL interface to perform fine-tuning
• View and interpret reports generated by Automatic
SQL Tuning

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
• Resource Manager
• Scheduler

AWR Baselines

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 set alert thresholds
– monitor performance
– compare advisor reports
Normal
AWR Baseline
time

Automatic Workload Repository Baselines
Oracle Database 11g further enhances the Automatic

Workload Repository baselines.
• Out-of-the-box Moving Window Baseline for which you
can specify adaptive thresholds
• Schedule the creation of a Baseline using Baseline
Templates
• Rename baselines, and set expiration dates for
baselines
Automatic Workload Repository Baselines

Oracle Database 11g consolidates the various concepts of baselines in Oracle, specifically
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 the moving window baselines. A system-defined
moving window baseline that corresponds to all the AWR data within the AWR retention period
is created by default.
In Oracle Database 11g baselines are enabled by default as long as
STATISTICS_LEVEL=TYPICAL or ALL.

Moving Window Baseline
There is one moving window baseline:

• SYSTEM_MOVING_WINDOW: A moving window baseline
that corresponds to the last 8 days of AWR data
• Created out-of-the-box in 11g
• By default, Adaptive thresholds functionality computes
stats on this Baseline
Moving Window Baseline

There is a system-defined moving window baseline created by default that corresponds to the
complete set of snapshot data within the AWR retention period. The N days setting is NULL,
therefore the window size always matches the AWR retention setting. 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.

Baselines in Performance Page Settings

Baseline Templates
• Allows you to schedule the creation of Baselines for

future time period(s) of interest
– Single Time Period in the future
– Repeating Schedule
• For example:
– A known holiday weekend
– Every Monday morning from 10am-2pm
• Once the Baseline Template has been specified for a
future time period, MMON will detect when the end
time has passed and will create the Baseline.
Baseline Templates
Creating baselines for future time periods allows you to mark time periods that you know will be
interesting. For example, you may want the system to automatically generate a baseline for every
Monday morning for the whole year, or you can ask the system to generate a baseline for an
upcoming holiday weekend if you suspect that it is a high-volume weekend. Previously, you could
only create baselines on snapshots that already existed. A nightly MMON task goes through all the
templates for baseline generation and checks to see if any time ranges have changed from the
future to the past within the last day. For the relevant time periods, the MMON task then creates a
baseline for the time period.

Creating AWR Baselines
Creating AWR Baselines

You can create two types of AWR Baselines: Single and Repeating. Both types are explained on
the slide.
To get access to the Baseline page, you can click the AWR Baselines link on the Server tab of the
Database Instance page.
Once on the Baseline page, click Create and follow the wizard to create your baseline.
Note: Before you can setup AWR Baseline Metric Thresholds for a particular baseline, you need
to compute the baseline statistics which is a possible action from the Baselines page. Other
possible actions not shown on the slide are Customize Performance Page, and Run AWR Report.

Single AWR Baseline
Single AWR Baseline

If you select the Single option in the previous step, you end up on the page shown on this slide.
There, you can select the time period corresponding to your interest.
Once done, click OK to create the static baseline.
Note: If both the Start Time and the End Time are in the future, a baseline template with the same
name as the baseline will be created.

Creating Repeating
Baseline Template
Creating Repeating Baseline Template

You can define repeating baselines using Enterprise Manager. In the wizard, once you selected
Repeating at step one, you can specify the repeat interval as shown on the slide.

Generate Baseline for
Single Time Period in Future
Interesting time
period
….. T4 T5 T6 ….. Tx Ty Tz
DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE_TEMPLATE ( -
start_time IN time stamp ,
end_time IN time stamp ,
baseline_name IN VARCHAR2 ,
template_name IN VARCHAR2 ,
expiration IN NUMBER ,
dbid IN NUMBER DEFAULT NULL ) ;
Generate Baseline for Single Time Period in Future

You can now create a template for how baselines are to be created for different time periods,
either in the future for predictable schedules or for past timelines. The Manageability
infrastructure generates a task using these inputs and automatically creates a baseline for the
specified time period, or for when the time comes. Using time-based definitions in the baseline
creation does not require to identify the start- and end- snapshot identifiers. For the
CREATE_BASELINE and CREATE_BASELINE_TEMPLATE procedures you can also now
specify an expiration duration. The expiration duration, specified in days, represents the number
of days you want the baselines to be maintained for. A value of NULL means the baselines never
expire.
The above example illustrates a template creation for a single time period.

Creating Repeating
Baseline Template
DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE_TEMPLATE ( -
day_of_week IN VARCHAR2,
hour_in_day IN NUMBER,
duration IN NUMBER,
start_time IN DATE,
end_time IN DATE
baseline_name_prefix IN VARCHAR2,
template_name IN VARCHAR2,
expiration IN NUMBER DEFAULT NULL,
dbid IN NUMBER DEFAULT NULL );
Creating Repeating Baseline Template

You can use the syntax above 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 wish the baseline to be automatically removed after a specified expiration interval
(expiration). The values of the CREATE_BASELINE_TEMPLATE procedure are:
• day_of_week: Day of week that the baseline should repeat on. Specify one of the
following values (‘SUNDAY’, ‘MONDAY’, ‘TUESDAY’, ‘WEDNESDAY’, ‘THURSDAY’,
‘FRIDAY’, ‘SATURDAY’).
• hour_in_day: A value of 0-23 specifies the hour in the day the baseline should start.
• duration: The duration (in hours) after hour_in_day that the baseline should last.
• start_time: Effective time to start generating baselines (once converted to nearest
snapshot ID.)
• end_time: Effective time to stop generating baselines (once converted to nearest snapshot
ID.)
• baseline_name_prefix: Name for baseline prefix. When creating the baseline, the
name of the baseline is the prefix appended with the date information.
• template_name: Name for the template
• expiration: The expiration (in days) to maintain the created baselines for. If NULL, then
expiration is infinite, meaning do not drop baseline ever. Defaults to NULL.
• dbid: Database Identifier for baseline. If NULL, then use the database identifier for the
local database. Defaults to NULL.

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_METRICS
DBMS_WORKLOAD_REPOSITORY Package
Oracle Database 11g offers the above set of PL/SQL interfaces in the
DBMS_WORKLOAD_REPOSITORY package for administration and filtering.
MODIFY_BASELINE_WINDOW_SIZE allows you to modify the size of the
SYSTEM_MOVING_WINDOW.

DBA_HIST_BASELINE Modified View
New column Description

BASELINE_TYPE Values: ‘Static’, ‘Moving Window’, or
‘Generated’.
MOVING_WINDOW_SIZE If Baseline Type is ‘Moving Window’,
this field is the size of the Moving
Window in number of days. If NULL,
then the window size is the value of the
AWR retention setting.
CREATION_TIME Time the Baseline was created
EXPIRATION Expiration setting for the Baseline in
number of Days. The Baseline is
maintained for this time period. NULL
keeps the Baseline data forever.
TEMPLATE_NAME Name of the template that created this
Baseline, if any
LAST_TIME_COMPUTED Last time adaptive threshold statistics
were computed over the baseline
DBA_HIST_BASELINE Modified View

For the baseline_type of Static, these baselines are created manually by you. For the
‘Moving Window’ Baseline, the Start and End Snapshot IDs are dynamic. The ‘Generated’
baselines are automatically generated by the system using a template.
SQL> desc dba_hist_baseline
Name Null? Type
--------------------------------- -------- ------------
DBID NUMBER
BASELINE_ID NUMBER
BASELINE_NAME VARCHAR2(64)
BASELINE_TYPE VARCHAR2(13)
START_SNAP_ID NUMBER
START_SNAP_TIME TIMESTAMP(3)
END_SNAP_ID NUMBER
END_SNAP_TIME TIMESTAMP(3)
MOVING_WINDOW_SIZE NUMBER
CREATION_TIME DATE
EXPIRATION NUMBER
TEMPLATE_NAME VARCHAR2(64)
LAST_TIME_COMPUTED DATE

DBA_HIST_BASELINE_DETAILS New View
New column Description

INSTANCE_NUMBER Instance ID for Baseline Data
SHUTDOWN Shows if there is a database
startup/shutdown in this interval. Can
take the values: (‘YES’, ‘NO’, NULL)
ERROR_COUNT Count of errors in the snapshots in the
Baseline snapshot range.
PCT_TOTAL_TIME Amount of time captured in snapshots
divided by the total possible time for
this Baseline.
LAST_TIME_COMPUTED Last time stats were computed on the
Baseline
DBA_HIST_BASELINE_DETAILS New View

Oracle Database 11g displays information that allows you to determine the validity of given
baseline. The PCT_TOTAL_TIME column provides a measure of how much of the snapshot data
exists within the baseline.
SQL> desc dba_hist_baseline_details
Name Null? Type
--------------------------------- -------- --------------
DBID NUMBER
INSTANCE_NUMBER NUMBER
BASELINE_ID NUMBER
BASELINE_NAME VARCHAR2(64)
BASELINE_TYPE VARCHAR2(13)
START_SNAP_ID NUMBER
START_SNAP_TIME TIMESTAMP(3)
END_SNAP_ID NUMBER
END_SNAP_TIME TIMESTAMP(3)
SHUTDOWN VARCHAR2(3)
ERROR_COUNT NUMBER
PCT_TOTAL_TIME NUMBER
LAST_TIME_COMPUTED DATE
MOVING_WINDOW_SIZE NUMBER
CREATION_TIME DATE
EXPIRATION NUMBER
TEMPLATE_NAME VARCHAR2(64)

DBA_HIST_BASELINE_TEMPLATE New View
Column Description
TEMPLATE_ID Internal ID for the template on how to generate the
baseline.
TEMPLATE_TYPE Values: ‘SINGLE’, ‘REPEATING’. ‘SINGLE’ means just one
time period. ‘REPEATING’ means to maintain a time period.
START_TIME Start Time for the future Baseline. Used for ‘SINGLE’. For
‘REPEATING’, this is the Effective Start Time where
Baselines should start being generated.
END_TIME End Time for the future Baseline. Used for ‘SINGLE’. For
‘REPEATING’, this is the Effective End Time where
Baselines should stop being generated.
DAY_OF_WEEK Day of week to create baseline. Is one of the following
values (‘SUNDAY’, ‘MONDAY’, ‘TUESDAY’, ‘WEDNESDAY’,
‘THURSDAY’, ‘FRIDAY’, ‘SATURDAY’, ‘ALL’). Used for
‘REPEATING’.
HOUR_IN_DAY Value of 0-23 to specify the Hour in the Day to create the
Baseline for. Used for ‘REPEATING’.
DURATION Length of the time period for Baseline to be created. Used

for ‘REPEATING’.
REPEAT_INTERVAL String that represents the time repeating information in the
DBMS_SCHEDULER format
LAST_GENERATED Last time a Baseline was generated for this template
DBA_HIST_BASELINE_TEMPLATE New View

SQL> desc dba_hist_baseline_template
Name Null? Type
------------------------------- -------- ------------------
DBID NOT NULL NUMBER
TEMPLATE_ID NOT NULL NUMBER
TEMPLATE_NAME NOT NULL VARCHAR2(30)
TEMPLATE_TYPE NOT NULL VARCHAR2(9)
BASELINE_NAME_PREFIX NOT NULL VARCHAR2(30)
START_TIME NOT NULL DATE
END_TIME NOT NULL DATE
DAY_OF_WEEK VARCHAR2(9)
HOUR_IN_DAY NUMBER
DURATION NUMBER
EXPIRATION NUMBER
REPEAT_INTERVAL VARCHAR2(128)
LAST_GENERATED DATE

Adaptive Thresholds

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 system moving window
– Manually computed over static baselines

• Baseline metric statistics can be used to determine

alert thresholds:
– Unusual values vs. baseline data = significance level
thresholds
– Close or exceeding peak value over baseline data =
percent of maximum thresholds

Defining Alert Thresholds Using Baseline
Defining Alert Thresholds Using Baseline

Once AWR baseline statistics are computed for a particular baseline, you can set metric
thresholds specific to your baseline.
You can compute baseline statistics directly from the Baselines page as discussed earlier.
Then, go to the AWR Baseline Metric Thresholds page, select the type of metrics you want to set.
Once 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 click Apply Thresholds.
You can specify thresholds based on statistics computed for your baseline. This is illustrated on
the slide. In addition to Significance Level, other possibilities are Percentage of Maximum, and
Fixed Values.
Note: Once a threshold is set using Baseline Metric Thresholds, the previous threshold values are
forgotten forever and the statistics from the associated baseline will drive threshold until they are
cleared (via Baseline Metric Threshold UI or PL/SQL interface).

Using EM to Quickly Configure Adaptive
Thresholds
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. You make the
selection of the appropriate workload profiles from the subsequent pop-up window.
By making this simple selection, the system will automatically configure and evolve Adaptive
Thresholds based on the SYSTEM_MOVING_WINDOW baseline for a group of metrics
corresponding best to the chosen workload.

Using EM to Quickly Configure Adaptive
Thresholds
Using EM to Quickly Configure Adaptive Thresholds

You then confirm the creation of the desired workload baselines. Once configured, you can edit
the threshold levels through the Edit Threshold button.
The Warning Level and Critical Level columns indicate the type of alert generated. The
Significance Level indicates if the level of observation is at or above a certain value. The
following significance level thresholds are supported:
• High, significant at 0.95 (5 in 100) level
• Very High, significant at 0.99 (1 in 100) level
• Severe, significant at 0.999 (1 in 1000) level
• Extreme, significant at 0.9999 (1 in 10,000) level
When editing threshold levels you are recommended to set significance level thresholds
conservatively and experimentally at first.
The threshold values are determined by examining 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 (the statistic basically) provided by you. This is significantly easier in the
multi-target 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
1000).

Changing Adaptive Threshold Settings
Threshold
adapts
automatically
Observed
value
Baseline
calculation
Changing Adaptive Threshold Settings

Once adaptive thresholds are set, you can change their values if need be. You can do so as shown
on the slide.
On the Edit AWR Baseline Metric Thresholds page corresponding to the metric you want to
modify, you can see the graphic history of the observed value for the metric as well as the
materialization of the computed baseline value, and the corresponding adaptive threshold.

V$SYSTEM_EVENT and
V$SYSTEM_WAIT_CLASS Changes
• V$SYSTEM_EVENT:
– TOTAL_WAITS_FG
– TOTAL_TIMEOUTS_FG
– TIME_WAITED_FG
– AVERAGE_WAIT_FG
– TIME_WAITED_MICRO_FG
• V$SYSTEM_WAIT_CLASS:
– TOTAL_WAITS_FG
– TIME_WAITED_FG
V$SYSTEM_EVENT has five new NUMBER columns that represent the statistics from purely
foreground sessions:
• TOTAL_WAITS_FG
• TOTAL_TIMEOUTS_FG
• TIME_WAITED_FG
• AVERAGE_WAIT_FG
• TIME_WAITED_MICRO_FG
V$SYSTEM_WAIT_CLASS has two new NUMBER columns that represent the statistics from
purely foreground sessions:
• TOTAL_WAITS_FG
• TIME_WAITED_FG

Automated Maintenance Tasks
10 p.m. – 2 a.m. Mon to Fri 6 a.m. – 2 a.m. Sat to Sun
Oracle Database 10g introduced the execution of some automated maintenance tasks during a
maintenance window. Specifically the automated task were: statistics collection and segment
advisor.
With Oracle Database 11g, the Automated Maintenance Tasks feature relies on the Resource
Manager being enabled during the Maintenance Windows. The idea is to prevent maintenance
work from consuming excessive amounts of system resources.
In order to facilitate mapping of automated tasks to specific windows, the above Maintenance
Windows are created in place of the existing WEEKNIGHT_WINDOW and
WEEKEND_WINDOW windows inside the MAINTENANCE_WINDOW_GROUP window
group.
You are still completely free to define other Maintenance Windows, as well as change start times
and durations for the windows listed above. Likewise, any Maintenance Windows that are deemed
unnecessary can be disabled or removed. The operations can be done using EM or Scheduler
interfaces.

11g New Features For Administrators Student Guide-5 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

11g New Features For Administrators Student Guide-5 PDF

Uploaded by

Copyright:

Available Formats

Practice 5: Overview

This practice covers the following topics:

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

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

Copyright © 2007, Oracle. All rights reserved.

After completing this lesson, you should be able to:

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

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

You can play the following mini lesson to better

Automatic SQL Tuning Overview (see URL in notes)

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

ASM Fast Disk Resync Overview

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

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

SQL Tuning in Oracle Database 10g

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

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

Automatic SQL Tuning in Oracle Database 11g

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

• Task runs automatically (Autotask Framework)

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

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

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

Automatic SQL Tuning in Oracle Database 11g

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

Automatic SQL Tuning task

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

Maintenance Window Timeline

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

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

Automatic Tuning Process

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

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

Auto-testing/implementing is limited to profiles because:

Testing is done for regular SQL tune tasks as well!

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

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

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

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

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

Automatic SQL Tuning Task

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

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

Automatic SQL Tuning Configuration

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

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

Automatic SQL Tuning Result Summary

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

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

Automatic SQL Tuning Result Recommendations

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

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

Automatic SQL Tuning Result Details

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

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

Automatic SQL Tuning Result Details Drilldown

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

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

Automatic SQL Tuning Fine Tune

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

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

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

Getting Reports Using PL/SQL Interface