Database Tuning Tools

Basic Tools (Dynamic Performance Views, Statistics, Metrics, EM pages)

AWR or Statspack
ADDM
DBA Scripts

Performance Tuning Methodology:

1. Data Collection
2. Data Analysis
3. Solution Implementation

Proactive monitoring with ADDM

Reactive monitoring with Server-generated alerts and AWR

Monitoring & Tuning Packs:

1. Oracle Database Diagnostic Pack (DBMS_WORKLOAD_REPOSITORY,

DBMS_ADVISOR, V$ACTIVE_SESSION_HISTORY, DBA_HIST_*,
DBA_ADVISOR_*
2. Oracle Database Tuning Pack (DBMS_SQLTUNE, DBMS_ADVISOR
3. Oracle Configuration Management Pack

Without Packs:

1. SQL Traces
2. Statspack
3. System statistics
4. Wait model
5. Time model
6. OS statistics
7. Metrics
8. Service statistics
9. Histograms
10. Optimizer statistics
11. SQL statistics

Tuning Methodology:
1. Check the OS stats and general machine health before tuning the instance.
2. Tune from the top down: Start with the design, then application, and then
instance.
3. Tune the area with greatest potential benefit. Identify the biggest bottleneck,
and tune it.
4. Stop tuning when you meet your goals.

General Tuning Session:

1. Define the problem and state the goal.
2. Collect current statistics, and compare them with baseline statistics.
3. Consider common performance errors.
4. Build a trial solution. Why performance degraded and how to resolve it.
 5. Implement and measure the change.
6. Did the solution meet the goals, if not, do it again.

Defining the Problem:

1. Listen to user feedback

2. Check the alert log and trace files for errors.
3. Check the parameter file for any diagnostic or inappropriate parameter setting.
4. Check for CPU and disk queuing, disk utilization, and memory swapping.
Identify processes and resource usage.
5. Use the available tools, such as Statspack or ADDM, to identify SQL
statements in the application that are consuming the most resources.
6. Collect instance and OS statistics.

Setting the Priority:

1. Choose the problem that has the greatest impact

2. Analyze the system performance in terms of work done (CPU or service time)
versus time spent waiting for work (wait time).
3. Determine which component consumes the greatest amount of time.
4. Drill down and tune that component, if appropriate.

Each server process is in one of the states:

- Idle: waiting for something to do or sleeping
- Running code: using the CPU or in run queue.
- Waiting (blocked): for some resource to become available or requested activity
to be completed.

Common Tuning Problems:

1. SQL statements or application tuning

2. Session management (connects, disconnects, open cursors, cursor caching)
3. Memory issues are high on the list of instance tuning problems. It includes
sizing different parts of SGA and contention of memory resources (Shared
pool sizing and contention, Buffer cache sizing and contention, data block
contention)
4. Redo log and redo buffer tuning (in OLTP applications).
5. Undo tuning and I/O issues
6. Locking issues

Tuning with ADDM:

1. View the ADDM report
a. Collect current stats, and compare with previous set.
b. Compare to performance issues knowledge base.
c. Define problem and make recommendations.
2. Review recommendations and build trial solution plan.
3. Implement the recommendations and measure the change.
4. Review the next ADDM report and decide "did the solution meet the goal?"

Tuning Objectives:
 1. Minimizing response time or reducing user wait time.
2. Increasing throughput, which means decreasing time to perform a job or set of
jobs.
3. Increasing load capabilities
4. Decreasing recovery time

DB Wait Time = sum of all waits for availability of resources.

DB CPU Time = sum of time spent working on the request.
DB Time = DB Wait Time + DB CPU Time

Tuning Life Cycle Phases:

1. Development: Application design and programming. Whenever possible,

tuning should be started at this level. With a good design, many tuning
problems do not occur. For example, typically, its good to fully normalize
tables to reduce redundancy, this can result in high number of table joins. By
demoralizing tables, performance can improve dramatically.
2. Testing: Database configuration
3. Deployment: Adding new application to an existing database
4. Production: Troubleshooting and tuning

Performance VS Safety Trade-Offs

Factors that affect the performance but increase security, recoverability:

1. Multiple control files, more writes
2. Multiple redo log members in a group
3. Frequent checkpointing
4. Backing up data files
5. Performing archiving
6. Block check sums
7. Number of concurrent users and connections

Monitoring and Tuning Tool: Overview

Services

Alert log
tkprof
Trace files
trcsess
Performance views

System statistics
Optimizer statistics Session statistics
SQL statistics Wait model
Base statistics Time model
Histograms
Metrics Alerts
Service statistics
ASH ASH reports

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

 Monitoring and Tuning Tool: Overview

Services

AWR AWR baselines

EM performance
pages Compare periods
Metric baseline
EM policies
ADDM
Advisors
Direct SGA monitor
Hang analyzer

Statspack Baselines

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

Performance Tuning: Type of Data Gathered

1. Cumulative statistics
a. Wait events with time information
b. Time model
2. Metrics: Statistic rates (per second, per transaction, per session)
3. Sample statistics: Active session history (data gathered in past)
a. Statistics by session
b. Statistics by SQL
c. Statistics by Service
d. Other dimensions

Performance Tuning: Tools

1. Basic
a. EM pages
b. Alert log (checkpoints, archiving, alter system commands etc)
c. Trace files (background processes problem logging)
User Trace files: can be generated at the request of DBA, Instance
level tracing is enabled by enabling SQL_TRACE parameter, Session
level tracing by issuing alter session set sql_trace=true;
Background processes trace files
d. Dynamic performance views and tables
2. Add-in: Statspack
3. Options:
a. Diagnostic pack (AWR)
b. Tuning pack

Dynamic Performance Views:

1. Owned by SYS user

2. Different views are available at different times
a. The instance has been started
 b. The database is mounted
c. The database is open
3. Query V$FIXED_TABLES to see all view names
4. These views are often referred as "v-dollar" views
5. Read consistency not guaranteed as data is dynamic

Statistics Level STATISTICAL_LEVEL

1. BASIC: No advisory or other statistical data is collected.

2. TYPICAL: This is default and recommended value.
3. ALL: Additional time OS statistics and row source execution stats.
4. Query V$STATISTICS_LEVEL to determine which other parameters are
affected by STATISTICAL_LEVEL parameter:
select statistics_name, activation_level from v$statistics_level

System wide statistics

V$SYSSTAT
V$SESSION
V$SESSION_EVENT
V$SESSION_WAIT
V$SGASTAT
V$EVENT_NAME
V$SYSTEM_EVENT
V$STATNAME
V$SERVICE_STATS
V$SERVICES
V$SERVICE_EVENT
V$SESSION_WAIT_CLASS

Wait Events