001Introduction to Oracle Performance Tuning

7/28/2019 001Introduction to Oracle Performance Tuning

1/6

4/13/13 Introduction to Oracle Performance Tuning

docs.oracle.com/cd/A58617_01/server.804/a58246/intro.htm

Oracle8 Tuning

Release 8.0

A58246-01 Library Product Contents Index

1

Introduction to Oracle Performance Tuning

The Oracle Server is a sophisticated and highly tunable software product. Its flexibility allows you to make small

adjustments that affect database performance. By tuning your system, you can tailor its performance to best meet

your needs.

This chapter gives an overview of tuning issues. Topics in this chapter include:

What Is Performance Tuning?

Who Tunes?

Setting Performance Targets

Setting User Expectations

Evaluating Performance

What Is Performance Tuning?

Performance must be built in! Performance tuning cannot be performed optimally after a system is put intoproduction. To achieve performance targets of response time, throughput, and constraints you must tune

application analysis, design, and implementation. This section introduces some fundamental concepts:

Trade-offs Between Response Time and Throughput

Critical Resources

Effects of Excessive Demand

Adjustments to Relieve Problems

Trade-offs Between Response Time and Throughput

Goals for tuning vary, depending on the needs of the application. Online transaction processing (OLTP)

applications define performance in terms of throughput. These applications must process thousands or even

millions of very small transactions per day. By contrast, decision support systems (DSS applications) define

performance in terms of response time. Demands on the database that are made by users of DSS applications

vary dramatically. One moment they may enter a query that fetches only a few records, and the next moment

they may enter a massive parallel query that fetches and sorts hundreds of thousands of records from various

different tables. Throughput becomes more of an issue when an application must support a large number of users

running DSS queries.
http://docs.oracle.com/cd/A58617_01/server.804/a58246/intro.htm#896http://docs.oracle.com/cd/A58617_01/server.804/a58246/intro.htm#858http://docs.oracle.com/cd/A58617_01/server.804/a58246/intro.htm#997http://docs.oracle.com/cd/A58617_01/server.804/a58246/intro.htm#2638http://docs.oracle.com/cd/A58617_01/server.804/a58246/intro.htm#915http://docs.oracle.com/cd/A58617_01/server.804/a58246/part1.htmhttp://docs.oracle.com/cd/A58617_01/server.804/a58246/method.htmhttp://docs.oracle.com/cd/A58617_01/index.htmhttp://docs.oracle.com/cd/A58617_01/server.804/a58246/intro.htm#896http://docs.oracle.com/cd/A58617_01/server.804/a58246/intro.htm#879http://docs.oracle.com/cd/A58617_01/server.804/a58246/intro.htm#858http://docs.oracle.com/cd/A58617_01/server.804/a58246/intro.htm#2959http://docs.oracle.com/cd/A58617_01/server.804/a58246/intro.htm#1018http://docs.oracle.com/cd/A58617_01/server.804/a58246/intro.htm#997http://docs.oracle.com/cd/A58617_01/server.804/a58246/intro.htm#2638http://docs.oracle.com/cd/A58617_01/server.804/a58246/intro.htm#915http://docs.oracle.com/cd/A58617_01/server.804/a58246/intro.htm#804http://docs.oracle.com/cd/A58617_01/server.804/a58246/method.htmhttp://docs.oracle.com/cd/A58617_01/server.804/a58246/part1.htmhttp://docs.oracle.com/cd/A58617_01/server.804/a58246/index.htmhttp://docs.oracle.com/cd/A58617_01/server.804/a58246/toc.htmhttp://docs.oracle.com/cd/A58617_01/server.804/index.htmhttp://docs.oracle.com/cd/A58617_01/index.htm


2/6



Response Time

Because response time equals service time plus wait time, you can increase performance in two ways:

by reducing service time

by reducing wait time

Figure 1-1 illustrates ten independent tasks competing for a single resource.

Figure 1-1 Sequential Processing of Multiple Independent Tasks

In this example only task 1 runs without having to wait. Task 2 must wait until task 1 has completed; task 3 must

wait until tasks 1 and 2 have completed, and so on. (Although the figure shows the independent tasks as the

same size, the size of the tasks will vary.)

Note:In parallel processing, if you have multiple resources, then more resources can be assigned to the tasks.Each independent task executes immediately using its own resource: no wait time is involved.

System Throughput

System throughput equals the amount of work accomplished in a given amount of time. Two techniques of

increasing throughput exist:

Get more work done with the same resources (reduce service time).

Get the work done quicker by reducing overall response time. To do this, look at the wait time. You may

be able to duplicate the resource for which all the users are waiting. For example, if the system is CPUbound you can add more CPUs.

Wait Time

The service time for a task may stay the same, but wait time will go up as contention increases. If many users are

waiting for a service that takes 1 second, the tenth user must wait 9 seconds for a service that takes 1 second.

Figure 1-2 Wait Time Rising with Increased Contention for a Resource
http://docs.oracle.com/cd/A58617_01/server.804/a58246/intro.htm#2974


3/6



Critical Resources

Resources such as CPUs, memory, I/O capacity, and network bandwidth are key to reducing service time.

Added resources make possible higher throughput and swifter response time. Performance depends on the

following:

How many resources are available?

How many clients need the resource?How long must they wait for the resource?

How long do they hold the resource?

Figure 1-3 shows that as the number of units requested rises, the time to service completion rises.

Figure 1-3 Time to Service Completion vs. Demand Rate

To manage this situation, you have two options:

You can limit demand rate to maintain acceptable response times.

Alternatively, you can add multiple resources: another CPU or disk.

Effects of Excessive Demand

Excessive demand gives rise to:

greatly increased response time

reduced throughput
http://docs.oracle.com/cd/A58617_01/server.804/a58246/intro.htm#2992


4/6



If there is any possibility of demand rate exceeding achievable throughput, a demand limiter is essential.

Figure 1-4 Increased Response Time/Reduced Throughput

Adjustments to Relieve Problems

Performance problems can be relieved by making the following adjustments:

adjusting unit

consumption

You can relieve some problems by using less resource per transaction or by reducing service

time. Or you can take other approaches, such as reducing the number of I/Os per transaction.

adjusting

functional

demand

Other problems can be abated by rescheduling or redistributing the work.

adjusting

capacity

You can also relieve problems by increasing or reallocating resource. If you start using multiple

CPUs, going from a single CPU to a symmetric multiprocessor, you will have multiple resourcesyou can use.

For example, if your system's busiest times are from 9:00 AM until 10:30, and from 1:00 PM until 2:30, you can

plan to run batch jobs in the background after 2:30, when more capacity is available. In this way you can spread

out the demand more evenly. Alternatively, you can allow for delays at peak times.

Figure 1-5 Adjusting Capacity and Functional Demand


5/6



Who Tunes?

Everyone involved with the system has some role in the tuning process. When people communicate and

document the system's characteristics, tuning becomes significantly easier and faster.

Figure 1-6 Who Tunes the System?

Business executives must define and then reexamine business rules and procedures to provide a clear andadequate model for application design. They must identify the specific kinds of rules and procedures that

can influence the performance of the whole system.

Application designers must design around potential performance bottlenecks. They must communicate the

system design so that everyone can understand the flow of data in an application.

Application developers must communicate the implementation strategies they choose so that modules and

SQL statements can be quickly and easily identified during statement tuning.

Database administrators (DBAs) must carefully monitor and document system activity so that they can

identify and correct unusual system performance.

Hardware and software administrators must document and communicate the configuration of the system

so that everyone can design and administer the system effectively.

Decisions made in application development and design have the most impact on performance. Once the

application is deployed, the database administrator usually has the primary responsibility for tuning-within the

limitations of the design.

See Also: Chapter 3, "Diagnosing Performance Problems in an Existing System" for keys that can help database

administrators (DBAs) to identify performance problems and solve them reactively.

Setting Performance TargetsWhether you are designing or maintaining a system, you should set specific performance goals so that you know

when to tune. You can spend needless time tuning your system without significant gain if you attempt to alter

initialization parameters or SQL statements without a specific goal.

When designing your system, set a specific goal: for example, an order entry response time of less than three

seconds. If the application does not meet that goal, identify the bottleneck causing the slowdown (for example,

I/O contention), determine the cause, and take corrective action. During development, you should test the

application to determine whether it meets the designed performance goals before deploying the application.
http://docs.oracle.com/cd/A58617_01/server.804/a58246/diagnose.htm#977


6/6



Tuning is usually a series of trade-offs. Once you have determined the bottlenecks, you may have to sacrifice

some other areas to achieve the desired results. For example, if I/O is a problem, you may need to purchase

more memory or more disks. If a purchase is not possible, you may have to limit the concurrency of the system

to achieve the desired performance. However, if you have clearly defined goals for performance, the decision on

what to trade for higher performance is simpler because you have identified the most important areas.

Setting User Expectations

Application developers and database administrators must be careful to set appropriate performance expectations

for users. When the system carries out a particularly complicated operation, response time may be slower than

when it is performing a simple operation. In cases like this, the slower response time is not unreasonable.

If a DBA should promise 1-second response time, consider how this might be interpreted. The DBA might mean

that the operation would take 1 second in the database-and might well be able to achieve this goal. However,

users querying over a network might experience a delay of a couple of seconds due to network traffic: they will

not receive the response they expect in 1 second.

Evaluating Performance

With clearly defined performance goals, you can readily determine when performance tuning has been successful

Success depends on the functional objectives you have established with the user community, your ability to

measure objectively whether or not the criteria are being met, and your ability to take corrective action to

overcome any exceptions. The rest of this tuning manual describes the tuning methodology in detail, with

information about diagnostic tools and the types of corrective actions you can take.

DBAs who are responsible for solving performance problems must keep a wide view of the all the factors that

together determine response time. The perceived area of performance problems is frequently not the actual

source of the problem. Users in the preceding example might conclude that there is a problem with the database,

whereas the actual problem is with the network. A DBA must monitor the network, disk, CPU, and so on, to

find the actual source of the problem-rather than simply assume that all performance problems stem from the

database.

Ongoing performance monitoring enables you to maintain a well-tuned system. Keeping a history of the

application's performance over time enables you to make useful comparisons. With data about actual resource

consumption for a range of loads, you can conduct objective scalability studies and from these predict the

resource requirements for load volumes you may anticipate in the future.

See Also: Chapter 4, "Overview of Diagnostic Tools"

Prev Next

Copyright 1997 Oracle Corporation.All Rights Reserved. Library Product Contents Index
http://docs.oracle.com/cd/A58617_01/server.804/a58246/index.htmhttp://docs.oracle.com/cd/A58617_01/server.804/a58246/toc.htmhttp://docs.oracle.com/cd/A58617_01/server.804/index.htmhttp://docs.oracle.com/cd/A58617_01/index.htmhttp://docs.oracle.com/cd/A58617_01/dcommon/html/cpyr.htmhttp://docs.oracle.com/cd/A58617_01/server.804/a58246/method.htmhttp://docs.oracle.com/cd/A58617_01/server.804/a58246/part1.htmhttp://docs.oracle.com/cd/A58617_01/server.804/a58246/tools.htm#1916

001Introduction to Oracle Performance Tuning

Documents

Transcript of 001Introduction to Oracle Performance Tuning