9 copyright © 2006, oracle. all rights reserved. automatic performance management

9Copyright © 2006, Oracle. All rights reserved.

Automatic Performance Management

9-2 Copyright © 2006, Oracle. All rights reserved.

Objectives

After completing this lesson, you should be able to:

• Diagnose database performance issues

• Configure the Automatic Workload Repository

• Access the database advisors

• Use the SQL Access Advisor to improve database performance

• Use asynchronous COMMIT effectively

TuningStatisticsSGA Attach AWR AdvisorsAsync. Commit


Tuning Activities

The three activities in performance management are:

• Performance planning

• Instance tuning

• SQL tuning


Performance Planning

• Investment options

• System architecture

• Scalability

• Application design principles

• Workload testing, modeling, and implementation

• Deploying new applications


Instance Tuning

• Have well-defined goals.

• Allocate memory to database structures.

• Consider I/O requirements in each part of the database.

• Tune the operating system for optimal performance of the database.


Performance Tuning Methodology

The tuning steps:

• Tune from the top down. Tune:– The design before tuning the application code– The code before tuning the instance

• Tune the area with the greatest potential benefit.– Identify the longest waits.– Identify the largest service times.

• Stop tuning when the goal is met.


Statistics Collection

• Performance tuning depends on the collection of accurate statistics.

• There are different types of statistics:– Optimizer statistics– System statistics

• There are different methods of collecting statistics:– Automatically, through GATHER_STATS_JOB– Manually, with the DBMS_STATS package– By setting database initialization parameters– By importing statistics from another database


Oracle Wait Events

• A collection of wait events provides informationabout the sessions or processes that had to wait or must wait for different reasons.

• These events are listed in the V$EVENT_NAME view.

Tuning> Statistics

SGA Attach AWR AdvisorsAsync. Commit


V$SGASTAT• pool• name• bytes

V$SYSSTAT• statistic# • name• class• value• stat_id

V$SYSTEM_EVENT• event• total_waits• total_timeouts• time_waited• average_wait• time_waited_micro

System Statistics

V$EVENT_NAME• event_number• event_id• name• parameter1 • parameter2 • parameter3• wait_class

V$SYSTEM_WAIT_CLASS• wait_class_id • wait_class#• wait_class• total_waits• time_waited


Displaying Session-Related Statistics

V$STATNAME• statistic# • name • class

V$SESSTAT• sid• statistic#• value

V$SESSION• sid• serial#• username• command• osuser• seq#• event#• event• p1/2/3text• p1/2/3• p1/2/3raw• wait_class• wait_time• seconds_in_wait• state• ...

V$SESSION_EVENT• sid• event• total_waits• total_timeouts• time_waited• average_wait• max_wait• time_waited_micro• event_id

V$EVENT_NAME• event#• name• parameter1• parameter2 • parameter3


Displaying Service-Related Statistics

For n-tier environments, because session statistics are not as helpful, you can see service-level statistics in these views:

• V$SERVICE_EVENT: Aggregated wait counts and wait times for each service, on a per event basis

• V$SERVICE_WAIT_CLASS: Aggregated wait counts and wait times for each service on a wait class basis


Instance/DatabaseV$DATABASEV$INSTANCEV$PARAMETERV$SPPARAMETERV$SYSTEM_PARAMETERV$PROCESSV$BGPROCESSV$PX_PROCESS_SYSSTAT

V$SYSTEM_EVENT

Troubleshooting and Tuning Views

DiskV$DATAFILEV$FILESTATV$LOGV$LOG_HISTORYV$DBFILEV$TEMPFILEV$TEMPSEG_USAGEV$SEGMENT_STATISTICS

ContentionV$LOCKV$UNDOSTATV$WAITSTATV$LATCH

MemoryV$BUFFER_POOL_STATISTICSV$LIBRARYCACHEV$SGAINFOV$PGASTAT


Dictionary Views

• The following dictionary and special views provide useful statistics after using the DBMS_STATS package:– DBA_TABLES, DBA_TAB_COLUMNS– DBA_CLUSTERS– DBA_INDEXES– DBA_TAB_HISTOGRAMS

• This statistical information is static until you reexecute the appropriate procedures in DBMS_STATS.


Diagnosis of Hung or Extremely Slow Databases

Use for problem analysis when the database is performing very slowly, or is hung:

• Direct access to SGA for performance monitoring (memory access mode)– V$SESSION– V$SESSION_WAIT– V$SYSTEM_EVENT– V$SYSSTAT– Hang analysis using Enterprise Manager

TuningStatistics

> SGA Attach AWR AdvisorsAsync. Commit


Using Memory Access Mode

1

23

4


Using the Hang Analysis Page

Micro-window


Automatic WorkloadRepository

SYSAUX

SGA

In-memorystatistics

6:00 a.m.7:00 a.m.

8:00 a.m.

Snapshot 1Snapshot 2Snapshot 3

Snapshot 49:00 a.m.

9:30 a.m.

ADDM finds top problems.MMON

TuningStatistics SGA Attach

> AWR AdvisorsAsync. Commit


AWR Snapshot Baselines

DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE ( - start_snap_id IN NUMBER , end_snap_id IN NUMBER , baseline_name IN VARCHAR2);

Relevant periodin the past


Advisory Framework:Overview

ADDM

SQL Tuning Advisor

SQL Access Advisor

Memory

Space

PGA Advisor

SGA

Segment Advisor

Undo Advisor

Buffer CacheAdvisor

Library CacheAdvisor

PGA

TuningStatistics SGA Attach AWR

> AdvisorsAsync. Commit


Database Control and Advisors


Typical Advisor Tuning Session

Adjust task parameters.

Acceptresults?

Implementrecommendations.

Yes

No

Perform analysis.

Create an advisor task.


Manually Invoking ADDM


Using the SQL Tuning Advisor: Review

• Use the SQL Tuning Advisor to analyze SQL statements and obtain performance recommendations.

• Sources for SQL Tuning Advisor to analyze:– Top SQL: Analyzes the top SQL statements

currently active– SQL Tuning Sets: Analyzes a set of SQL statements

you provide– Snapshots: Analyzes a snapshot– Baselines: Analyzes a baseline


SQL Access Advisor: Overview

SQL Access

Advisor

Recommendations-Indexes-Materialized views-Materialized view logs

Workload specification-SQL statement-SQL Tuning Set-SQL cache contents-Statistics-Schema name


Typical SQL Access Advisor Session


Workload Source


Recommendation Options


Reviewing Recommendations


Asynchronous COMMIT

• The default COMMIT behavior is to wait until redo is saved in the redo log files.

• The default behavior can now be changed to “not wait.”

• Asynchronous COMMIT is useful for high transaction throughput.

• However, transactions may be lost.– Machine crashes– File I/O problems with redo log files

TuningStatistics SGA Attach AWR Advisors

> Async. Commit


Using Asynchronous COMMIT

• Possible combinations:– IMMEDIATE, WAIT (this is the default)– IMMEDIATE, NOWAIT– BATCH, WAIT– BATCH, NOWAIT

• System- or session-level examples:

• COMMIT statement examples:

ALTER SYSTEM SET COMMIT_WRITE = IMMEDIATE, WAIT

ALTER SESSION SET COMMIT_WRITE = IMMEDIATE, NOWAIT

COMMIT WRITE BATCH WAIT

COMMIT WRITE BATCH NOWAIT


Summary

In this lesson, you should have learned how to:

• Diagnose database performance issues

• Configure the Automatic Workload Repository

• Access the database advisors

• Use the SQL Access Advisor to improve database performance

• Use asynchronous COMMIT effectively


Practice Overview: Using ADDM to Diagnose Performance Problems

This practice covers the following topics:

• Viewing and interpreting ADDM findings to diagnose a performance problem

• Implementing those findings

9 copyright © 2006, oracle. all rights reserved. automatic performance management

Documents

wait v

event v

session v

instance v

sysstat v

value v

lock v

tempfile v