Nothing Special   »   [go: up one dir, main page]

Oracle Performance Tunng

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 3

1 Performance Tuning Overview

This chapter provides an introduction to performance tuning and contains the following sections:

Introduction to Performance Tuning Introduction to Performance Tuning Features and Tools

1.1 Introduction to Performance Tuning


This guide provides information about tuning Oracle Database for performance. Topics discussed in this guide include: Performance Planning Instance Tuning SQL Tuning See Also:

Oracle Database 2 Day + Performance Tuning Guide to learn how to use Oracle
Enterprise Manager to tune database performance

1.1.1 Performance Planning


You should complete Part II, "Performance Planning" before proceeding to other parts of this guide. Based on years of designing and performance experience, Oracle has designed a performance methodology. This part describes activities that can dramatically improve system performance and contains the following topics:

Understanding Investment Options Understanding Scalability System Architecture Application Design Principles Workload Testing, Modeling, and Implementation Deploying New Applications

1.1.2 Instance Tuning


Part III, "Optimizing Instance Performance" discusses the factors involved in the tuning and optimizing of an Oracle database instance. When considering instance tuning, take care in the initial design of the database to avoid bottlenecks that could lead to performance problems. In addition, you must consider:

Allocating memory to database structures

Determining I/O requirements of different parts of the database Tuning the operating system for optimal performance of the database

After the database instance has been installed and configured, you must monitor the database as it is running to check for performance-related problems. 1.1.2.1 Performance Principles Performance tuning requires a different, although related, method to the initial configuration of a system. Configuring a system involves allocating resources in an ordered manner so that the initial system configuration is functional. Tuning is driven by identifying the most significant bottleneck and making the appropriate changes to reduce or eliminate the effect of that bottleneck. Usually, tuning is performed reactively, either while the system is in preproduction or after it is live. 1.1.2.2 Baselines The most effective way to tune is to have an established performance baseline that you can use for comparison if a performance issue arises. Most database administrators (DBAs) know their system well and can easily identify peak usage periods. For example, the peak periods could be between 10.00am and 12.00pm and also between 1.30pm and 3.00pm. This could include a batch window of 12.00am midnight to 6am. It is important to identify these peak periods at the site and install a monitoring tool that gathers performance data for those high-load times. Optimally, data gathering should be configured from when the application is in its initial trial phase during the QA cycle. Otherwise, this should be configured when the system is first in production. Ideally, baseline data gathered should include the following:

Application statistics (transaction volumes, response time) Database statistics Operating system statistics Disk I/O statistics Network statistics

In the Automatic Workload Repository, baselines are identified by a range of snapshots that are preserved for future comparisons. See "Overview of the Automatic Workload Repository". 1.1.2.3 The Symptoms and the Problems A common pitfall in performance tuning is to mistake the symptoms of a problem for the actual problem itself. It is important to recognize that many performance statistics

indicate the symptoms, and that identifying the symptom is not sufficient data to implement a remedy. For example:

Slow physical I/O Generally, this is caused by poorly-configured disks. However, it could also be caused by a significant amount of unnecessary physical I/O on those disks issued by poorly-tuned SQL.

Latch contention Rarely is latch contention tunable by reconfiguring the instance. Rather, latch contention usually is resolved through application changes.

Excessive CPU usage Excessive CPU usage usually means that there is little idle CPU on the system. This could be caused by an inadequately-sized system, by untuned SQL statements, or by inefficient application programs.

You might also like