Database Tuning Tools

Basic Tools (Dynamic Performance Views, Statistics, Metrics, EM pages)AWR or StatspackADDMDBA Scripts

Performance Tuning Methodology:1. Data Collection2. Data Analysis3. Solution Implementation

Proactive monitoring with ADDMReactive 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_ADVISOR3. Oracle Configuration Management Pack

Without Packs:

1. SQL Traces2. Statspack3. System statistics4. Wait model5. Time model6. OS statistics7. Metrics8. Service statistics9. Histograms10. Optimizer statistics11. 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 feedback2. 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 impact2. 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 tuning2. 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 issues6. 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 capabilities4. 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 configuration3. Deployment: Adding new application to an existing database4. Production: Troubleshooting and tuning

Performance VS Safety Trade-Offs

Factors that affect the performance but increase security, recoverability:1. Multiple control files, more writes2. Multiple redo log members in a group3. Frequent checkpointing4. Backing up data files5. Performing archiving6. Block check sums7. Number of concurrent users and connections

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

Monitoring and Tuning Tool: Overview

Alert logTrace files

Performance views

Optimizer statisticsSQL statisticsBase statistics

HistogramsMetrics

Service statisticsASH

tkproftrcsess

System statisticsSession statistics

Wait modelTime model

Alerts

ASH reports

Services

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

Monitoring and Tuning Tool: Overview

Statspack

AWR

EM performance pages

Metric baselineEM policies

ADDMAdvisors

Direct SGA monitorHang analyzer

Baselines

AWR baselines

Compare periods

Services

Performance Tuning: Type of Data Gathered

1. Cumulative statisticsa. Wait events with time informationb. 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 sessionb. Statistics by SQLc. Statistics by Serviced. Other dimensions

Performance Tuning: Tools

1. Basica. EM pagesb. 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 tables2. Add-in: Statspack3. Options:

a. Diagnostic pack (AWR)b. Tuning pack

Dynamic Performance Views:

1. Owned by SYS user2. Different views are available at different times

a. The instance has been started

b. The database is mountedc. The database is open

3. Query V$FIXED_TABLES to see all view names4. These views are often referred as "v-dollar" views5. 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$SYSSTATV$SESSIONV$SESSION_EVENTV$SESSION_WAITV$SGASTATV$EVENT_NAMEV$SYSTEM_EVENTV$STATNAMEV$SERVICE_STATSV$SERVICESV$SERVICE_EVENTV$SESSION_WAIT_CLASS

Wait Events