Performance_PLaning

8/7/2019 Performance_PLaning

1/66

Oracle9i

Database Performance Planning

Release 2 (9.2)

March 2002

Part No. A96532-01


2/66

Oracle9i Database Performance Planning, Release 2 (9.2)

Part No. A96532-01

Copyright 2001, 2002 Oracle Corporation. All rights reserved.

Primary Author: Andrew Holdsworth

Contributing Au thor: Lenore Luscher

Contr ibutor s: Jorn Bartels, Maria Colgan, Michele Cyran , Bjorn Engsig, Cecilia Gervasio, Conn ie DialerisGreen, Mattias Jankow itz, Peter Kilpatr ick, Anjo Kolk, JP Polk, Virag Saksena , Sabrina Whiteh ouse,Graham Wood

Graph ic Designer: Valarie Moore

The Programs (which include both the software and d ocumentation) contain proprietary information ofOracle Corporation; they are pr ovided u nd er a license agreement containing restrictions on u se anddisclosure and are also protected by copyright, patent and other intellectual and ind ustrial propertylaws. Reverse engineering, disassembly or d ecompilation of the Progr ams, except to the extent requiredto obtain interoperability with oth er indep enden tly created software or as sp ecified by law, is prohibited.

The information contained in this docum ent is subject to change w ithout notice. If you find any p roblemsin the documenta tion, please report them to us in writing. Oracle Corporation does not warr ant that this

docum ent is error-free. Except as ma y be expressly perm itted in your license agreement for thesePrograms, no part of these Programs may be reprodu ced or transmitted in an y form or by any means,electronic or mechanical, for any pu rpose, withou t the express written p ermission of Oracle Corporation.

If the Programs are d elivered to the U.S. Governmen t or anyon e licensing or using the p rogram s onbehalf of the U.S. Government, the following notice is applicable:

Restricted Rights Notice Program s delivered su bject to the DOD FAR Sup plement are "comm ercialcompu ter software" and use, dup lication, and disclosure of the Programs, includ ing docum entation,shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement.Otherw ise, Programs d elivered su bject to the Federal Acquisition Regulations are "restricted compu ter

software" and u se, dup lication, and disclosure of th e Program s shall be subject to the restrictions in FAR52.227-19, Comm ercial Comp uter Software - Restricted Rights (Jun e, 1987). Oracle Corp oration , 500Oracle Par kw ay, Redw ood City, CA 94065.

The Programs are n ot intended for use in any n uclear, aviation, mass tran sit, med ical, or other inherentlydan gerous ap plications. It shall be the licensee's responsibility to take all app ropriate fail-safe, backup ,redu nd ancy, and other m easures to ensure the safe use of such applications if the Program s are used forsuch pu rposes, and Or acle Corporation d isclaims liability for any dam ages caused by such use of thePrograms.

Oracle is a registered trad emark, an d Oracle Store, Oracle9i, PL/ SQL, and SQL*Plus are trad ema rks or

registered trad emarks of Oracle Corpor ation. Other names m ay be tradem arks of their respectiveowners.


3/66

iii

Contents

Send Us Your Comments .................................................................................................................... v

Preface........................................................................................................................................................... vii

1 Designing and Developing for PerformanceOracles N ew Methodology .............................................................................................................. 1-2

Understanding Investment Options ............................................................................................... 1-2

Understanding Scalability ................................................................................................................ 1-3

What is Scalability?....................................................................................................................... 1-3

Intern et Scalability ........................................................................................................................ 1-4

Factors Preventing Scalability ..................................................................................................... 1-6

System Architecture ........................................................................................................................... 1-7

Hardware and Software Components....................................................................................... 1-7

Configuring the Right System Architecture for Your Requirements.................................. 1-10

Application Design Principles ...................................................................................................... 1-14

Simp licity In Ap plication Design ............................................................................................. 1-14

Data Modelin g ............................................................................................................................ 1-14

Table and Index Design ............................................................................................................. 1-15Using Views................................................................................................................................. 1-18

SQL Execution Efficiency .......................................................................................................... 1-18

Implem entin g the Ap plication ................................................................................................. 1-20

Tren ds in Ap plication Develop ment ....................................................................................... 1-22

Workload Testing, Modeling, and Implementation ................................................................... 1-23

Sizing Data ................................................................................................................................... 1-23

Estimating Workloads ............................................................................................................... 1-23
http://comments_template.pdf/http://comments_template.pdf/


4/66

iv

Application Modeling ................................................................................................................ 1-25

Testing, Debugging, and Validating a Design........................................................................ 1-25Deploying N ew Applications......................................................................................................... 1-27

Rollou t Strategies ........................................................................................................................ 1-27

Performance Checklist ............................................................................................................... 1-27

2 Monitoring and Improving Application Performance

Importance of Statistics ..................................................................................................................... 2-2Statistics Gathering Tools ............................................................................................................ 2-6

Importance of Historical Data and Baselines............................................................................ 2-8

Performance Intuition .................................................................................................................. 2-8

The Oracle Performance Improvement Method ........................................................................... 2-9

Introduction to Performance Improvement.............................................................................. 2-9

Steps in The Oracle Performance Improvement Meth od ..................................................... 2-11

How to Check the Operating System....................................................................................... 2-12A Sample Decision Process for Performance Conceptual Modeling .................................. 2-12

Top Ten Mistakes Found in Oracle Systems........................................................................... 2-14

Perform ance Character istics of H ardware Configurat ions .................................................. 2-16

3 Emergency Performance Techniques

Introduction to Emergency Performance Techniques .................................................................. 3-2

Steps in the Emergency Performance Method .............................................................................. 3-2

Index


5/66

v

Send Us Your Comments

Oracle9iDatabase Performance Planning, Release 2 (9.2)

Part No. A96532-01

Oracle Corpora tion welcomes your comm ents and suggestions on the qua lity and usefulness of this

docum ent. Your inp ut is an imp ortant p art of the information u sed for revision.

s Did you find any errors?

s Is the information clearly presented ?

s Do you n eed m ore information? If so, where?

s Are the examp les correct? Do you n eed m ore examples?

s What features did you like most?

If you find any errors or have any oth er suggestions for improvement , please indicate the document

title and p art num ber, and the chap ter, section, and p age nu mber (if available). You can send com-men ts to us in the following ways:

s Electronic mail: infod ev_u [email protected]

s FAX: (650) 506-7227 Attn: Server Technologies Docu mentat ion Manager

s Postal service:

Oracle Corporation

Server Technologies Documentation

500 Oracle Parkway, Mailstop 4op11

Redw ood Shores, CA 94065

USA

If you w ould like a reply, please give your nam e, add ress, telephone n um ber, and (optionally) elec-

tronic mail add ress.

If you have p roblems with the software, please contact your local Oracle Sup port Services.


6/66

vi


7/66

vii

Preface

This book describes ways to improve Oracle performance by starting with good

app lication design an d u sing statistics to monitor ap plication p erformance. It

explains the Oracle Performance Improvem ent Method , as welll as emergency

performance techniqu es for dealing with p erformance problems.

This preface contains these topics:

s Audience

s Organization

s Related Documentation

s Conventions

s Documentation Accessibility


8/66

viii

AudienceOracle9i Database Performance Planning is a high-level aid for p eople responsible for

the op eration, maintenance, and p erformance of Oracle. To use this book, you could

be a d atabase ad ministrator, application d esigner, programm er, or man ager. You

should be familiar w ith Oracle9i, the opera ting system, and ap plication d esign

before reading this manu al.

OrganizationThis docum ent contains:

Chapter 1, "Designing and Developing for Performance"

This chapter d escribes performance issues to consider when d esigning Oracle

applications.

Chapter 2, "Monitoring and Improving Application Performance"This chapter d escribes the Oracle Performance Improvem ent Method and theimportance of statistics for ap plication p erformance improvemen ts.

Chapter 3, "Emergency Performance Techniques"

This chap ter describes techniqu es for d ealing w ith performance emergencies.

Related DocumentationBefore reading this man ual, you should have already read Oracle9i Database

Concepts, the Oracle9i A pplication Developers Guide - Fundamentals, and the Oracle9i

Database Administrators Guide.

For more information abou t Oracle Enterprise Manager and its optional

app lications, see Oracle Enterprise Manager Concepts Guide an d Oracle Enterprise

Manager Administrators Guide.

For more information abou t tuning the Oracle App lication Server, see the Oracle

Application Server Performance and Tuning Guide.

Many of the examples in th is book use the sample schem as of the seed d atabase,

which is installed by d efault wh en you install Oracle. Refer to Oracle9i Sample

Schemas for information on how these schemas were created and how you can use

them you rself.

In Nor th Am erica, printed docum entation is available for sale in the Oracle Store at


9/66

ix

http://oraclestore.oracle.com/

Custom ers in Europe, the Midd le East, and Africa (EMEA) can p urchase

documentation from

http://www.oraclebookshop.com/

Other custom ers can contact their Oracle representative to pu rchase printed

documentation.

To dow nload free release notes, installation d ocumen tation, wh ite papers, or other

collateral, p lease visit the Oracle Technology N etw ork (OTN). You m ust register

online before using OTN ; registration is free and can be d one at

http://otn.oracle.com/admin/account/membership.html

If you already have a username an d password for OTN, then you can go directly to

the d ocumen tation section of the OTN Web site at

http://otn.oracle.com/docs/index.htm

To access the database documentation search engine directly, please visit

http://tahiti.oracle.com

Conventions

This section describes the conventions used in the text and code examples of the thisdocum entation set. It describes:

s Convention s in Text

s Conventions in Code Examples

Conventions in Text

We use var ious conventions in text to help you more qu ickly identify special terms.The following table describes those conventions an d provid es examples of their use.


10/66

x

Conventions in Code Examples

Code examp les illustrate SQL, PL/ SQL, SQL*Plus, or other comm and -line

statements. They are displayed in a monosp ace (fixed-wid th) font and separated

from normal text as shown in th is examp le:

SELECT username FROM dba_users WHERE username = MIGRATE;

The following table describes typograp hic conventions u sed in code examp les and

provid es examples of their use.

Convention Meaning Example

Bold Bold typ eface indicates terms that aredefined in the text or terms that app ear ina glossary, or both.

When you specify this clause, you create anindex-organized table.

Italics Italic typeface indicates book titles,emp hasis, syntax clauses, or placeholders.

Oracle9i Database Concepts

You can sp ecify the parallel_clause.

Run Uold_release.SQL where old_releaserefers to the release you installed p rior to

upgrading.

UPPERCASEmonospace(fixed-width font)

Uppercase monospace typeface indicateselements sup plied by th e system. Suchelements include parameters, privileges,datatypes, RMAN keywords, SQLkeywords, SQL*Plus or u tility command s,packages and m ethods, as well assystem-supp lied column names, databaseobjects and structu res, user names, androles.

You can specify this clause only for a NUMBERcolumn.

You can back up the da tabase using the BACKUPcommand.

Query the TABLE_NAME column in the USER_TABLES data dictionary view.

Specify the ROLLBACK_SEGMENTS parameter.

Use the DBMS_STATS.GENERATE_STATSprocedure.

lowercasemonospace(fixed-width font)

Lowercase monosp ace typeface ind icatesexecutables and sample user-suppliedelements. Such elements includ ecomp uter and database names, netservice nam es, and connect identifiers, as

well as user-supp lied d atabase objectsand structures, column names, packagesand classes, user names and roles,program u nits, and p arameter values.

Enter sqlplus to open SQL*Plus.

The department_id, department_name,and location_id colum ns are in thehr.departments table.

Set the QUERY_REWRITE_ENABLEDinitialization parameter to true.

Connect as oe user.


11/66

xi


[ ] Brackets en close one or m ore op tion alitems. Do not enter th e brackets.

DECIMAL (digits [ , precision ])

{ } Braces enclose two or more item s, one ofwh ich is required. Do not enter th ebraces.

{ENABLE | DISABLE}

| A vertical bar represents a choice of twoor more opt ions within brackets or braces.

Enter one of the options. Do not enter thevertical bar.

{ENABLE | DISABLE}

[COMPRESS | NOCOMPRESS]

... Hor izontal ellipsis points ind icate either:

s That we have omitted parts of thecode that are not d irectly related tothe example

s That you can repeat a portion of thecode

CREATE TABLE ... AS subquery;

SELECT col1, col2, ... , coln FROM

employees;

.

.

.

Vertical ellipsis points indicate tha t w ehave om itted several lines of code notdirectly related to the example.

SQL> SELECT NAME FROM V$DATAFILE;

NAME

------------------------------------

/fsl/dbs/tbs_01.dbf

/fs1/dbs/tbs_02.dbf

.

.

.

/fsl/dbs/tbs_09.dbf9 rows selected.

Other notation You must enter symbols other thanbrackets, braces, vertical bars, an d ellipsispoint s as it is show n.

acctbal NUMBER(11,2);

acct CONSTANT NUMBER(4) := 3;

Italics Italicized text ind icates var iables forwh ich you m ust supp ly particular values.

CONNECT SYSTEM/system_password

UPPERCASE Upp ercase typeface indicates elementssupp lied by the system. We show theseterms in up percase in order to distingu ishthem from term s you define. Unless termsapp ear in brackets, enter them in theorder and with the spelling shown.How ever, because these terms are notcase sensitive, you can enter them inlowercase.

SELECT last_name, employee_id FROMemployees;

SELECT * FROM USER_TABLES;

DROP TABLE hr.employees;


12/66

xii

Documentation AccessibilityOur goal is to make Oracle produ cts, services, and sup porting d ocumen tation

accessible, with good usability, to the disabled commu nity. To tha t end , our

docum entation includ es features that m ake information available to users of

assistive technology. This documentation is available in HTML format, and contains

markup to facilitate access by the d isabled comm un ity. Stand ards w ill continu e to

evolve over time, and Oracle Corporation is actively engaged w ith other

market-leading technology vendors to ad dress technical obstacles so that ou r

docum entation can be accessible to all of our customers. For ad ditional information,

visit the Oracle Accessibility Program Web site athttp://www.oracle.com/accessibility/

Accessibility of Code Examples in Documentation JAWS, a Windows screen

reader, may not always correctly read th e code examples in this docum ent. The

conventions for w riting code requ ire that closing braces should app ear on an

otherw ise empty line; how ever, JAWS may not always read a line of text that

consists solely of a bracket or brace.

Accessibility of Links to External Web Sites in Documentation This

docum entation m ay contain links to Web sites of other comp anies or organizations

that Oracle Corporation d oes not own or control. Oracle Corporation neither

evaluates nor makes any rep resentations regarding the accessibility of these Web

sites.

lowercase Lowercase typeface ind icatesprogramm atic elements that you su pp ly.For example, lowercase ind icates nam esof tables, colum ns, or files.

SELECT last_name, employee_id FROM

employees;

sqlplus hr/hr



13/66

Designing and Developing for Performance 1-1

1Designing and Developing for Performance

Good system perform ance begins with d esign and continues throu ghou t the life of

your system. Carefully consider p erformance issues d uring th e initial design ph ase,

and it will be easier to tun e your system du ring produ ction.

This chap ter contains th e following sections:

s Oracles New Methodology

s Understanding Investment Options

s Und erstand ing Scalability

s System Architecture

s App lication Design Principles

s Workload Testing, Modeling, and Implementation

s Deploying New App lications


14/66

Oracles New Methodology

1-2 Oracle9i Database Performance Planning

Oracles New MethodologySystem performance has become increasingly important as computer systems get

larger and more comp lex and as the Internet p lays a bigger role in bu siness

app lications. In order to accommod ate this, Oracle Corporation has d esigned a new

performance method ology. It is based on year s of Oracle designing an d

performance experience, and it explains clear and simple activities that can

dramatically improve system performance.

Performance strategies vary in their effectiveness, and systems w ith d ifferent

pu rposes, such as operational systems and decision sup port systems, requ iredifferent p erformance skills. This book examines the considerations that any

da tabase designer, administrator, or performance expert shou ld focus their efforts

on .

System performance is designed and built into a system. It does not just happ en.

Performance problems are usu ally the result of contention for, or exhaustion of,

some system resource. When a system resource is exhau sted, the system is un able to

scale to higher levels of performance. This new performance methodology is basedon careful p lanning an d d esign of the da tabase, to prevent system resources from

becoming exhausted and causing down-time. By eliminating resource conflicts,

systems can be made scalable to the levels required by the bu siness.

Understanding Investment OptionsWith the availability of relatively inexpensive, high-powered processors, mem ory,

and disk dr ives, there is a temp tation to buy m ore system resources to improve

performance. In man y situations, new CPUs, memory, or more disk dr ives can

indeed p rovide an immed iate performance improvement. How ever, any

performance increases achieved by adding hardware should be considered a

short-term relief to an immediate problem. If the dem and and load rates on the

app lication continue to grow, then th e chance that you will face the same p roblem

in the near future is very likely.In other situat ions, additional hardw are does not imp rove the system's performance

at all. Poorly designed systems perform poorly no matter how m uch extra hardw are

is allocated. Before pu rchasing ad ditional hard ware, make sure that th ere is no

serialization or single threading going on w ithin the ap plication. Long-term, it is

generally more valuable to increase the efficiency of your application in terms of the

nu mber of physical resources used for each business transaction.

See Also: Oracle9i Database Performance Tuning Guide and Reference


15/66

Understanding Scalability


Understanding ScalabilityThe word scalability is used in m any contexts in developm ent environments. The

following section provid es an explana tion of scalability that is aimed at ap plication

designers and performance specialists.

What is Scalability?Scalability is a systems ability to process more workload, w ith a p roportional

increase in system resource usage. In other word s, in a scalable system, if youdou ble the workload, then the system wou ld u se twice as man y system resources.

This soun ds obvious, but d ue to conflicts within th e system, the resource usage

might exceed twice the original workload .

Examples of bad scalability due to resource conflicts includ e the following:

s App lications requiring significant concurrency managem ent as user

pop ulations increase

s Increased locking activities

s Increased d ata consistency workload

s Increased operating system w orkload

s Transactions requiring increases in d ata access as data volum es increase

s Poor SQL and index d esign resu lting in a higher n um ber of logical I/ Os for the

same num ber of rows returned

s Redu ced availability, because d atabase objects take longer to mainta in

An app lication is said to be u nscalable if it exhausts a system resource to the p oint

where no m ore through pu t is possible when its workload is increased. Such

applications result in fixed throughputs and poor response times.

Examples of resource exhaustion includ e the following:

s Hard ware exhaustion

s Table scans in h igh-volum e transactions causing inevitable d isk I/ O shortages

s Excessive network requests, resulting in network and schedu ling bottlenecks

s Memory allocation causing p aging and swapp ing

s Excessive process and thread allocation causing operating system th rashing


16/66



This mean s that app lication d esigners must create a design tha t uses the same

resources, regardless of user pop ulations and d ata volum es, and does not pu t loadson the system resources beyond their limits.

Internet ScalabilityApp lications that are accessible through the Internet have more comp lex

performance and availability requirements. Some ap plications are designed and

written only for Internet u se, but even typical back-office app lications, such as a

general ledger ap plication, might requ ire some or all data to be available online.Characteristics of Internet age ap plications includ e the following:

s Availability 24 hour s a day, 365 days a year

s Unp redictable and imprecise nu mber of concurrent u sers

s Difficulty in capacity p lanning

s Availability for an y typ e of query

s Multitier a rchitectures

s Stateless mid dlew are

s Rapid development timescale

s Minimal time for testing


17/66



Figure 11 Internet Workload Growth Curve

Figure 11 illustrates the classic Internet/ e-business and d eman d grow th curve,

with d emand growing at an increasing rate. Applications must scale w ith the

increase of workload and also wh en add itional hardw are is add ed to sup port

increasing dem and . Design errors can cause the implementation to reach its

maximu m, regardless of additional hard ware resources or re-design efforts.

Internet app lications are challenged by very short d evelopmen t timeframes withlimited time for testing and evaluation. How ever, bad d esign generally mean s that

at some p oint in the futu re, the system w ill need to be re-architected or

re-implemented. If an application with known architectural and implementation

limitations is dep loyed on the Internet, and if the workload exceeds the an ticipated

dem and , then there is real chance of failure in the futu re. From a business

persp ective, poor performance can mean a loss of custom ers. If Web users d o not

get a response in seven second s, then the u sers attention could be lost forever.

In many cases, the cost of re-designing a system with the associated downtime costs

in migrating to new implementations exceeds the costs of properly building the

original system. The moral of the story is simp le: design and im plement w ith

scalability in m ind from the start.

Time

RequiredWorkloa

d


18/66



Factors Preventing Scalability

When building app lications, designers and architects should aim for as close toper fect scalability as possible. This is sometimes called linearscalability, w here

system throughp ut is directly proportional to the num ber of CPUs.

In real life, linear scalability is impossible for reasons beyond a designers control.

How ever, making the application d esign and im plemen tation as scalable as possible

should ensure that current an d futu re performan ce objectives can be achieved

through expansion of hard ware comp onents and the evolution of CPU technology.

Factors Preventing Linear Scalability

1. Poor App lication Design, Imp lementation, and Configu ration

The application h as the biggest impact on scalability. For examp le:

s Poor schema d esign can cause expensive SQL that d oes not scale.

s Poor transaction design can cause locking and serialization problems.

s Poor connection managemen t can cause poor response times and u nreliable

systems.

However, the design is not the only problem. The physical imp lementation of

the ap plication can be the weak link. For examp le:

s Systems can move to prod uction environments with bad I/ O strategies.

s The produ ction environm ent could u se different execution p lans than those

generated in testing.

s Memory-intensive app lications that allocate a large amou nt of mem ory

without m uch though t for freeing the m emory at ru ntime can cause

excessive m emory usage.

s Inefficient mem ory usage and mem ory leaks pu t a high stress on the

operating virtu al memory subsystem. This imp acts performance and

availability.

2. Incorrect Sizing of Hardw are Components

Bad capacity planning of all hardware compon ents is becoming less of a

problem as relative hard ware prices decrease. How ever, too much capacity can

mask scalability problems as the w orkload is increased on a system .


19/66

System Architecture


3. Limitations of Software Compon ents

All software components have scalability and resource usage limitations. Thisapp lies to app lication servers, database servers, and op erating systems.

App lication design should not place demand s on the software beyond w hat it

can h andle.

4. Limitations of H ardw are Components

Hardw are is not p erfectly scalable. Most mu ltiprocessor machines can get close

to linear scaling with a finite nu mber of CPUs, but after a certain point each

add itional CPU can increase performan ce overall, but not p roportionately.

There might come a time w hen an additional CPU offers no increase in

performance, or even degrad es performan ce. This behavior is very closely

linked to th e workload and the operating system setup.

System ArchitectureThere are two m ain pa rts to a systems architecture:

s Hard ware and Software Components

s Configur ing the Right System Architecture for Your Requirements

Hardware and Software Components

Hardware Components

Todays designers an d architects are responsible for sizing an d capacity plann ing of

hardware at each tier in a multitier environment. It is the architect's responsibility to

achieve a balanced d esign. This is analogous to a bridge designer wh o mu st

consider all the various payload and structura l requ irements for the bridge. Abridge is only as strong as its weakest comp onent. As a result, a bridge is designed

in balance, such th at all comp onents reach their design limits simu ltaneously.

Note: These factors are based on Oracle Corporations Server

Performance group s experience of tun ing u nscalable systems.


20/66

System Architecture


The main h ardw are comp onents are the following:

s CPU

s Memory

s I/ O Subsystem

s Network

CPU There can be one or m ore CPUs, and they can vary in p rocessing pow er from

simple CPUs foun d in h and -held devices to high-pow ered server CPUs. Sizing ofother hard ware comp onents is usu ally a mu ltiple of the CPUs on the system.

Memory Database and app lication servers require considerable amou nts of mem oryto cache data and avoid time-consum ing disk access.

I/O Subsystem The I/ O subsystem can vary between th e hard d isk on a client PC andhigh p erformance disk arrays. Disk arrays can p erform thou sand s of I/ Os each

second and p rovide availability through red un dancy in terms of mu ltiple I/ O path sand hot pluggable mirrored d isks.

Network All compu ters in a system are connected to a network, from a m odem lineto a high speed internal LAN. The pr imary concerns with n etwork specifications are

bandw idth (volume) and latency (speed).

Software Components

The same way comp uters have common hardw are comp onents, app lications have

common functional comp onents. By dividing software d evelopmen t into fun ctional

compon ents, it is possible to comp rehend the application design and architecture

better. Some comp onents of the system are p erformed by existing software bought

to accelerate application imp lementation or to avoid re-developm ent of comm on

components.

The difference between software comp onents and hard ware comp onents is that

while hardw are comp onents only perform one task, a piece of software can p erform

the roles of various software comp onents. For examp le, a d isk drive only stores and

retrieves da ta, but a client program can manage the user interface and perform

business logic.


for more information on tu ning these resources


21/66

System Architecture


Most app lications involve the following compon ents:

s Managing the User Interface

s Implementing Business Logic

s Managing User Requests and Resource Allocation

s Managing Data an d Transactions

Managing the User Interface This comp onent is the m ost visible to app lication u sers.

This includes the following fun ctions:s Painting the screen in front of the user

s Collecting u ser data and transferring it to business logic

s Validating d ata entry

s Navigating throu gh levels or states of the ap plication

Implementing Business Logic This compon ent imp lements core business rules that arecentral to the app lication function. Errors mad e in this comp onent could be very

costly to repair. This comp onent is imp lemented by a m ixture of declarative and

procedu ral app roaches. An examp le of a declarative activity is defining u nique and

foreign keys. An examp le of procedu re-based logic is implementing a d iscoun ting

strategy.

Comm on functions of this comp onent include the following :

s Moving a data m odel to a relational table structure

s Defining constraints in the relational table structure

s Coding p rocedu ral logic to imp lement business rules

Managing User Requests and Resource Allocation This compon ent is imp lemented in allpieces of software. How ever, there are some requests and resources that can be

influenced by the ap plication d esign and some that cannot.

In a mu ltiuser app lication, most resource allocation by user requ ests are hand led by

the database server or the operating system. How ever, in a large application wh ere

the nu mber of users and their usage pattern is unknow n or growing rap idly, the

system architect mu st be proactive to ensu re that no single software comp onent

becomes overloaded and unstable.


22/66

System Architecture


Comm on functions of this comp onent include the following:

s Connection management w ith the database

s Executing SQL efficiently (cursors and SQL sharing)

s Managing client state information

s Balancing the load of u ser requests across hard ware resources

s Setting operational targets for hard ware/ software comp onents

s

Persistent qu euing for asynchronou s execution of tasks

Managing Data and Transactions This comp onent is largely the responsibility of thedatabase server and the operating system.

Comm on functions of this comp onent include the following:

s Providing concurrent access to data u sing locks and transactional semantics

s Providing optim ized access to the data u sing ind exes and mem ory cache

s Ensuring tha t data changes are logged in the event of a hardw are failure

s Enforcing any ru les defined for the data

Configuring the Right System Architecture for Your RequirementsConfiguring th e initial system architecture is a largely iterative process. Architects

mu st satisfy the system requiremen ts within budget and schedule constraints. If the

system requires interactive users transacting business or making decisions based onthe contents of a database, then u ser requirements d rive the architecture. If there are

few interactive users on the system, then the a rchitecture is process-dr iven.

Examples of interactive u ser applications:

s Accounting and bookkeeping applications

s Order entry systems

s Email servers

s Web-based retail applications

s Trad ing systems


23/66

System Architecture


Examples of p rocess-dr iven ap plications:

s Utility billing systems

s Fraud detection systems

s Direct mail

In many ways, process-dr iven app lications are easier to design than m ultiuser

app lications because the user interface element is eliminated . How ever, because the

objectives are process-oriented, architects not accustomed to dealing with large data

volum es and different success factors can become confused. Process-drivenapp lications draw from th e skills sets used in both user-based app lications and da ta

warehousing. Therefore, this book focuses on evolving system architectures for

interactive users.

The following qu estions should stimulate thou ght on architecture, thou gh they are

not a definitive guide to system architecture. These questions demonstrate how

business requiremen ts can influence the architecture, ease of imp lementation, and

overall performan ce and availability of a system. For examp le:

s

How many u sers will the system supp ort?Most applications fall into one of the following categories:

Very few u sers on a lightly-used or exclusive machine

For this type of app lication, there is u sually one u ser. The focus of th e

app lication design is to make the single user as p rodu ctive as possible by

provid ing good response time, yet make the app lication require minimal

administration. Users of these app lications rarely interfere with each other

and have m inimal resource conflicts.

A m edium to large number of users in a corporation u sing shared

applications

For this type of app lication, the users are limited by the nu mber of

emp loyees in the corporation actually transacting bu siness through the

system. Therefore, the nu mber of users is pred ictable. However, delivering

a reliable service is crucial to the business. The users will be using a shared

Note: Generating a system architecture is nota determ inistic

process. It requ ires careful consideration of bu siness requirements,

technology choices, existing infrastructure and systems, and actual

ph ysical resources, such as budget and m anp ower.

S t A hit t


24/66

System Architecture


resource, so design efforts must ad dress response time und er heavy system

load, escalation of resource for each session usage, and room for futu re

growth.

An infinite user popu lation d istributed on th e Internet

For this type of application, extra engineering effort is required to ensu re

that n o system comp onent exceeds its design limits. This would create a

bottleneck that brings th e system to a halt and becomes unstable. These

app lications requ ire comp lex load balancing, stateless app lication servers,

and efficient d atabase connection m anagem ent. In ad dition, statistics andgovernors shou ld be used to ensure that th e user gets some feedback if their

requests cannot be satisfied due to system overload.

s What w ill be the user interaction method ?

The choices of user interface range from a simp le Web browser to a custom

client program.

s Where are the users located?

The distance between users influences how the app lication is engineered to

cope with netw ork latencies. The location also affects which times of the d ay are

busy, when it is imp ossible to perform batch or system m aintenance fun ctions.

s What is the network speed?

Network speed affects the amoun t of data and th e conversational natu re of the

user interface with th e app lication and database servers. A highly

conversational user interface can comm un icate with back-end servers on everykey stroke or field level validat ion. A less conversational interface works on a

screen-sent and a screen-received m odel. On a slow network , it is imp ossible to

get good d ata entry speeds with a highly conversational user interface.

s How mu ch data w ill the user access, and how mu ch of that data is largely read

only?

The amou nt of da ta qu eried online influences all aspects of the d esign, from

table and index design to the presentation layers. Design efforts must ensu rethat u ser response time is not a fun ction of the size of the database. If the

app lication is largely read only, then replication an d data d istribution to local

caches in th e application servers become a viable option. This also redu ces

workload on the core transactional server.

s What is the user respon se time requ irement?

System Architecture


25/66

System Architecture


Consideration of the user typ e is important. If the user is an executive who

requires accurate information to m ake split second decisions, then u serresponse time cannot be comp romised. Other typ es of users, such as users

performing d ata entry activities, might not need such a h igh level of

performance.

s Do u sers expect 24 hour service?

This is mand atory for today's Internet ap plications where trade is condu cted 24

hours a day. How ever, corporate systems that ru n in a single time zone migh t

be able to tolerate after-hours dow ntime. This after-hou rs dow ntime can beused to run batch processes or to perform system adm inistration. In this case, it

might be more economic not to ru n a fu lly-available system.

s Must all changes be mad e in real time?

It is importan t to determ ine if transactions need to be executed w ithin the user

response time, or if they can they be qu eued for asynchronou s execution.

The following are secondary questions, which can also influence the d esign, but

really have m ore imp act on budget and ease of imp lementation. For example:

s How big will the d atabase be?

This influences the sizing of the d atabase server machine. On systems w ith a

very large database, it might be necessary to have a bigger machine than

dictated by the w orkload. This is because the adm inistration overhead w ith

large databases is largely a function of the d atabase size. As tables and indexes

grow, it takes propor tionately more CPUs to allow table reorganizations and

index bu ilds to complete in an acceptable time limit.

s What is the required th rough pu t of business transactions?

s What are the availability requiremen ts?

s Do skills exist to build and administer this app lication?

s What comp romises will be forced by budget constraints?

Application Design Principles


26/66



Application Design PrinciplesThis section d escribes design d ecisions that are involved in building app lications.

Simplicity In Application DesignApp lications are no d ifferent than any other designed and engineered p roduct.

Well-designed stru ctures, machines, and tools are u sually reliable, easy to u se and

maintain, and simple in concept. In the most general terms, if the d esign looks right,

then it probably is right. This principle shou ld always be kept in mind w hen

building applications.

Consider some of the following design issues:

s If the table design is so comp licated th at nobod y can fully und erstand it, then

the table is probably designed bad ly.

s If SQL statements are so long and involved that it wou ld be imp ossible for any

optimizer to effectively optimize it in real time, then th ere is probably a bad

statement, un derlying tran saction, or table design.

s If there are indexes on a table and th e same colum ns are repeatedly indexed,

then there is probably a bad ind ex design.

s If queries are subm itted w ithout su itable qualification for rapid response for

online users, then there is probably a bad u ser interface or transaction d esign.

s If the calls to the d atabase are abstracted aw ay from the app lication logic by

many layers of software, then there is probably a bad software developmen t

method.

Data ModelingData m odeling is impor tant to su ccessful relational app lication d esign. This shou ld

be don e in a w ay tha t qu ickly represents the bu siness practices. Chances are, there

will be heated debates about the correct data m odel. The imp ortant th ing is to app ly

greatest mod eling efforts to those entities affected by the most frequen t bu siness

transactions. In the mod eling phase, there is a great temptation to spen d too m uch

time mod eling the non -core data elements, wh ich results in increased developm ent

lead times. Use of mod eling tools can then rap idly generate schema d efinitions and

can be useful when a fast prototype is required.



27/66



Table and Index Design

Table design is largely a comprom ise between flexibility an d performance of coretransactions. To keep the da tabase flexible and able to accomm odate un foreseen

workloads, the table design should be very similar to the data m odel, and it should

be norm alized to at least 3rd norm al form. How ever, certain core transactions

required by u sers can requ ire selective denorm alization for performance pu rposes.

Examples of this techniqu e includ e storing tables pre-joined, the ad dition of derived

colum ns, and aggregate values. Oracle provid es num erous options for storage of

aggregates and p re-joined d ata by clustering and m aterialized view functions.These features allow a simp ler table design to be adopted initially.

Again, focus an d resources shou ld be spent on th e business critical tables, so that

good performance can be achieved. For non-critical tables, shortcuts in d esign can

be adop ted to enable a more rap id application developmen t. If, how ever, in

prototyp ing and testing a non-core table becomes a perform ance problem, then

remed ial design effort should be app lied imm ediately.

Index d esign is also a largely iterative process, based on the SQL generated byapp lication d esigners. How ever, it is possible to make a sensible start by bu ilding

indexes that enforce primary key constraints and ind exes on know n access patterns,

such as a person's nam e. As the app lication evolves and testing is performed on

realistic sizes of da ta, certain qu eries will need p erformance imp rovemen ts for

which building a better index is a good solution. The following list of indexing

design ideas should be considered w hen building a new index:

s App end ing Column s to an Ind ex or Using Index-Organized Tables

s Using a Different Ind ex Type

s Find ing the Cost of an Ind ex

s Serializing within Ind exes

s Ordering Colum ns in an Index

Appending Columns to an Index or Using Index-Organized TablesOne of the easiest ways to speed u p a query is to redu ce the num ber of logical I/ Os

by eliminating a table access from the execution plan. This can be d one by

app end ing to the ind ex all columns referenced by the qu ery. These colum ns are the

select list colum ns an d any requ ired join or sort colum ns. This techniqu e is

par ticularly useful in speed ing up on line app lications response times when

time-consum ing I/ Os are reduced. This is best app lied w hen testing the ap plication

with properly sized data for the first time.



28/66

pp g p


The most aggressive form of this techniqu e is to build an index-organized table

(IOT). How ever, you m ust be careful that the increased leaf size of an IOT does not

un derm ine the efforts to redu ce I/ O.

Using a Different Index Type

There are several index types available, and each index has benefits for certain

situations. The following list gives performance ideas associated with each ind ex

type.

B-Tree Indexes These are the standard ind ex type, and they are excellent for primarykey an d highly-selective ind exes. Used as concatenated indexes, B-tree ind exes can

be used to retrieve data sorted by the index columns.

Bitmap Indexes These are suitable for low cardinality data . Through comp ressiontechniques, they can generate a large number of rowids w ith minimal I/ O.

Combining bitmap indexes on n on-selective columns allows efficient AND an d OR

operations w ith a great num ber of rowid s with m inimal I/ O. Bitmap indexes are

par ticularly efficient in queries w ith COUNT(), because the qu ery can be satisfiedwithin the ind ex.

Function-based Indexes These ind exes allow access through a B-tree on a valuederived from a fun ction on the base da ta. Fun ction-based indexes have some

limitations with regards to the use of nulls, and they require that you have the

cost-based op timizer enabled.

Function-based ind exes are particularly useful when qu erying on compositecolum ns to prod uce a derived resu lt or to overcome limitations in the way da ta is

stored in the d atabase. An example of this is querying for line items in an order

exceeding a certain value d erived from (sales price - discoun t) x quantity, where

these were colum ns in the table. Another example is to app ly the UPPER function to

the d ata to allow case-insensitive searches.

Partitioned Indexes Partitioning a global index allows par tition pruning to take p lacewithin an ind ex access, which results in redu ced I/ Os. By definition of good range

or list partitioning, fast ind ex scans of the correct index partitions can result in very

fast query times.




29/66


Reverse Key Indexes These are designed to eliminate ind ex hot spots on insertapplications. These indexes are excellent for insert performance, but they are limited

in that they cannot be used for ind ex range scans.

Finding the Cost of an Index

Building an d m aintaining an ind ex structu re can be expensive, and it can consum e

resources such as d isk space, CPU, and I/ O capacity. Designers m ust ensure tha t

the benefits of any ind ex outw eigh the negatives of index mainten ance.

Use this simple estimation gu ide for the cost of index m aintenance: Each ind exmaintained by an INSERT, DELETE, or UPDATE of the ind exed keys requires about

three times as mu ch resource as the actual DML operation on the table. What th is

mean s is that if you INSERT into a table with three ind exes, then it will be

app roximately 10 times slower than an INSERT into a table with no ind exes. For

DML, and par ticularly for INSERT-heavy app lications, the ind ex design should be

seriously reviewed , which might require a comp romise between the query an d

INSERT performance.

Serializing within Indexes

Use of sequences, or timestamp s, to generate key values that are indexed

them selves can lead to database hotspot p roblems, which affect response time and

throu ghp ut. This is usually the result of a mon otonically growing key that resu lts in

a right-growing index. To avoid th is problem, try to generate keys that insert over

the full range of the ind ex. This results in a w ell-balanced ind ex that is more

scalable and space efficient. You can achieve this by using a reverse key index or

using a cycling sequence to prefix and sequence values.

Ordering Columns in an Index

Designers should be flexible in defining any ru les for index building. Depending on

your circumstan ces, use one of the following tw o ways to order the keys in an

index:

1. Order colum ns most selectivity first. This meth od is the most comm only used ,

because it provides the fastest access with minimal I/ O to the actual rowids

required. This technique is used m ainly for pr imary keys and for very selective

range scans.

2. Order colum ns to redu ce I/ O by clustering or sorting d ata. In large range scans,

I/ Os can u sually be reduced by ordering th e colum ns in the least selective

order, or in a manner that sorts the d ata in the way it shou ld be retrieved.



30/66


Using Views

Views can speed up an d simp lify app lication design. A simp le view d efinition canmask d ata mod el comp lexity from the p rogrammers w hose priorities are to retrieve,

display, collect, and store data.

How ever, while views provide clean program ming interfaces, they can cause

sub-optimal, resource-intensive queries. The w orst type of view use is wh en a view

references other view s, and w hen they are joined in queries. In m any cases,

developers can satisfy the qu ery directly from the table withou t using a view.

Usually, because of their inherent prop erties, views m ake it d ifficult for the

optimizer to generate the optimal execution p lan.

SQL Execution EfficiencyIn the design and architecture phase of any system d evelopmen t, care should be

taken to ensure tha t the app lication developers und erstand SQL execution

efficiency. To do this, the developm ent env ironment mu st support the following

characteristics:

s Good Database Connection Management

Connecting to the database is an expensive operation that is highly un scalable.

Therefore, the nu mber of concur rent connections to the d atabase should be

minim ized as much as possible. A simple system, wh ere a user connects at

app lication initialization, is ideal. However, in a Web-based or m ultitiered

app lication, where app lication servers are used to mu ltiplex da tabase

connections to users, this can be difficult. With these typ es of app lications,design efforts should ensure that d atabase connections are pooled and are not

reestablished for each u ser request.

s Good Cursor Usage and Management

Maintaining user connections is equally imp ortant to m inimizing the par sing

activity on the system. Parsing is the process of interpreting a SQL statement

and creating an execution p lan for it. This process has many p hases, includ ing

syntax checking, security checking, execution p lan genera tion, and loadingshared stru ctures into the shared pool. There are two typ es of par se operations:

s Hard Parsing . A SQL statement is submitted for the first time, and n o

match is found in the shared pool. Hard p arses are the most

resource-intensive and un scalable, because they perform all the opera tions

involved in a parse.



31/66


s Soft Parsing. A SQL statement is submitted for the first time, and a match is

found in the shared pool. The match can be the result of previous execution

by another u ser. The SQL statemen t is shared, w hich is good for

performance. However, soft parses are not id eal, because they still require

syntax and security checking, which consum e system resources.

Because parsing shou ld be minimized as m uch as p ossible, app lication

developers shou ld d esign their app lications to parse SQL statements once and

execute th em m any tim es. This is done th rough cursors. Experienced SQL

program mers shou ld be familiar w ith the concept of opening and re-executing

cursors.

App lication developers must also ensure that SQL statements are shared within

the shared pool. To do th is, bind variables to represent the p arts of the query

that chan ge from execution to execution. If this is not d one, then the SQL

statement is likely to be parsed on ce and n ever re-used by oth er users. To

ensure tha t SQL is shared, use bind variables and d o not u se string literals with

SQL statements. For examp le:

Statemen t w ith string literals:

SELECT * FROM emp

WHERE ename

LIKE KING;

Statemen t with bind variables:

SELECT * FROM emp

WHERE enameLIKE :1;

The following example show s the results of some tests on a simp le OLTP

application:

Test #Users Supported

No Parsing all statements 270

Soft Parsing all statements 150

Hard Parsing all statements 60

Re-Connecting for each Transaction 30

These tests were p erformed on a four-CPU m achine. The d ifferences increase as

the nu mber of CPUs on the system increase.



32/66


Implementing the Application

The choice of developmen t environmen t and p rogramming langu age is largely afunction of the skills available in the development team and architectura l decisions

mad e wh en specifying the ap plication. There are, however, some simp le

performance management ru les that can lead to scalable, high-performan ce

applications.

1. Choose a development environment suitable for software components, and do

not let it limit your d esign for performan ce decisions. If it does, then you

probably chose the w rong language or environment.

s User Interface

The programming mod el can v ary between H TML generation an d calling

the wind owing system d irectly. The development method shou ld focus on

respon se time of the u ser interface code. If HTML or Java is being sen t over

a netw ork, then try to minimize network volum e and interactions.

s Business Logic

Interpreted languages, such as Java an d PL/ SQL, are ideal to encode

business logic. They are fully por table, which makes u pgrading logic

relatively easy. Both languages are syntactically rich to allow code that is

easy to read and interpret. If business logic requires comp lex mathem atical

functions, then a comp iled binary language m ight be needed . The business

logic code can be on the client m achine, the app lication server, and the

database server. How ever, the app lication server is the most common

location for business logic.s User Requests and Resource Allocation

Most of this is not affected by the p rogramming language, but tools and 4th

generation languages that mask database connection and cursor

man agemen t might u se inefficient mechanisms. When evaluating these

tools and environments, check their database connection model and their

use of cursors and bind variables.

s Data Managem ent and Transactions

Most of this is not affected by the p rogramming language.

2. When imp lementing a software component, implement its function an d not the

functionality associated with other comp onents. Imp lementing anoth er

compon ents fun ctionality results in sub-optimal designs and implementations.

This applies to all comp onents.



33/66


3. Do not leave gaps in fun ctionality or have software comp onents

un der-researched in design, implemen tation, or testing. In m any cases, gaps are

not d iscovered u ntil the application is rolled ou t or tested a t realistic volum es.

This is u sually a sign of poor a rchitecture or initial system specification. Data

archival/ purge m odu les are most frequently neglected d uring initial system

design, build, and implementation.

4. When implementing procedural logic, implement in a procedural language,

such as C, Java, PL/ SQL. When imp lementing data access (queries) or d ata

changes (DML), use SQL. This ru le is specific to the bu siness logic modules of

code wh ere procedural code is mixed w ith da ta access (non-procedu ral SQL)code. There is great tem ptation to p ut p rocedu ral logic into the SQL access. This

tends to result in p oor SQL that is resource-intensive. SQL statements w ith

DECODE case statemen ts are very often candid ates for optimization, as are

statements with a large amoun t ofOR pred icates or set operators, such as UNION

an d MINUS.

5. Cache frequen tly accessed, rarely changing d ata th at is expensive to retrieve on

a repeated basis. How ever, make this cache mechanism easy to u se, and ensurethat it is really cheaper th an accessing the d ata in the original method . This is

app licable to all mod ules where frequen tly used d ata values shou ld be cached

or stored locally, rather than be repeatedly retrieved from a remote or expensive

data store.

The most comm on examp les of candid ates for local caching includ e the

following:

s

Today's date. SELECT SYSDATE FROM DUAL can accoun t for over 60% of theworkload on a d atabase.

s The current u ser name.

s Repeated ap plication var iables and constants, such as tax rates, discoun ting

rates, or location information.

s Caching data locally can be fur ther extended into building a local data

cache into th e application server m idd le tiers. This helps take load off the

central database servers. However, care should be taken w hen constructing

local caches so that th ey do not become so complex that they cease to give a

performance gain.

s Local sequen ce generation.

The design implications of using a cache shou ld be considered . For examp le, if

a user is connected at m idnight and the date is cached, then the d ate value he

has becomes invalid.



34/66


6. Optimize the interfaces between comp onents, and ensu re that all components

are used in the most scalable configu ration. This rule requires minimal

explanation and app lies to all modu les and their interfaces.

7. Use foreign key references. Enforcing referential integrity through an

application is expensive. You can m ainta in a foreign key reference by selecting

the column value of the child from th e parent and ensuring that it exists. The

foreign key constraint enforcement su pp lied by O racle (which does not u se

SQL) is fast, easy to declare, and does not create network traffic.

Trends in Application DevelopmentThe two biggest challenges in application developmen t today are the increased use

of Java to replace comp iled C or C++ ap plications, and increased use of

object-oriented techniques, influencing the schem a d esign.

Java p rovides better portability of code and availability to program mers. How ever,

there are a nu mber of performance imp lications associated w ith Java. Because Java

is an interpreted language, it is slower at executing similar logic than comp iled

languages such as C. As a result, resource usage of client machines increases. This

requires more pow erful CPUs to be app lied in th e client or mid dle-tier machines

and greater care from program mers to prod uce efficient code.

Because Java is an object-oriented language, it encourages insulation of data access

into classes not performing the bu siness logic. As a result, programm ers might

invoke meth ods w ithout kn owledge of the efficiency of the d ata access method

being used . This tends to result in d atabase access that is very minimal and uses the

simplest and crudest interfaces to the database.

With th is type of software design, queries do not alw ays includ e all the WHERE

predicates to be efficient, and row filtering is perform ed in the Java p rogram. This is

very inefficient. In add ition, for DML operat ions, and esp ecially for INSERTs, single

INSERTs are performed , making u se of the array interface imp ossible. In some

cases, this is mad e m ore inefficient by procedu re calls. More resources are u sed

moving the d ata to and from the database than in the actual database calls.

In general, it is best to place da ta access calls next to the bu siness logic to achievethe best overall transaction design.

The acceptance of object-orientation at a program ming level has led to th e creation

of object-oriented databases within the Oracle Server. This has manifested itself in

man y ways, from storing object structures within BLOBs and only using the

da tabase effectively as an indexed card file to the u se of the Oracle object relational

features.

Workload Testing, Modeling, and Implementation


35/66


If you ad opt an object-oriented ap proach to schema design, then make sure that you

do not lose the flexibility of the relational storage mod el. In many cases, the

object-oriented approach to schem a design ends up in a heavily denorm alized data

structure that requ ires considerable maintenance and REF pointers associated w ith

objects. Often, these designs represent a step backward to the hierarchical and

network database designs that w ere replaced with the relational storage m ethod.

In summ ary, if you are storing your d ata in your d atabase for the long-term and you

anticipate a degree of ad h oc queries or app lication d evelopmen t on the same

schema, then you w ill probably find that the relational storage method gives the

best p erformance an d flexibility.


Sizing DataYou could experience errors in you r sizing estimates wh en d ealing w ith variable

length data if you w ork with a p oor samp le set. Also, as data volumes grow, yourkey lengths could grow considerably, altering your assum ptions for column sizes.

When th e system becomes operational it becomes hard er to predict database

grow th, especially that of ind exes. Tables grow over time, and ind exes are subject to

the ind ividua l behavior of the ap plication in terms of key generation, insertion

patt ern, and deletion of rows. The w orst case is where you insert u sing an

ascending key and then d elete most row s from the left-hand side bu t not all the

rows. This leaves gaps and wasted space. If you h ave index use like this make surethat you know how to use the online ind ex rebuild facility.

Most good DBAs monitor space allocation for each object and look for objects that

could grow out of control. A good u nd erstand ing of the app lication can highlight

objects that could g row rap idly or u np redictably. This is a crucial part of both

performance and availability plann ing for any system. When implementing the

produ ction database, the d esign should attempt to ensure that m inimal space

managem ent takes place when interactive users are using the app lication. This

app lies for all data, temp , and rollback segments.

Estimating WorkloadsEstimation of workloads for capacity plann ing and testing pu rposes is often

described as a black art. When considering th e number of variables involved it is

easy to see w hy this p rocess is largely imp ossible to get p recisely correct. However,

designers need to specify machines with CPUs, memory, and disk d rives, and



36/66


eventually roll out an app lication. There are a nu mber of techniques used for sizing,

and each techniqu e has merit. When sizing, it is best to use at least two m ethods to

validate your decision-making process and provide sup porting d ocum entation.

Extrapolating From a Similar System

This is an en tirely empirical approach wh ere an existing system of similar

characteristics and know n p erformance is used as a basis system. The specification

of this system is then mod ified by the sizing specialist according to the known

differences. This approach has merit in that it correlates with an existing system, but

it provides little assistance wh en d ealing with the d ifferences.

This app roach is used in n early all large engineering disciplines when p reparing th e

cost of an engineering p roject be it a large building, a ship , a bridge, or an oil rig. If

the reference system is an order of magn itud e different in size from th e anticipated

system, then some of the compon ents could have exceeded their design limits.

Benchmarking

The benchmarking p rocess is both resource and time consum ing, and it might notget the correct results. By simulating in a benchm ark an app lication in early

development or p rototype form, there is a d anger of measuring something that has

no resemblance to the actual p rodu ction system. This sound s strange, but over the

man y years of benchmarking custom er applications with the database developm ent

organization, we have yet to see good correlation between the benchm ark

app lication and th e actual prod uction system. This is mainly due to the number of

app lication inefficiencies introdu ced in the d evelopmen t p rocess.

How ever, benchm arks have been used successfully to size systems to an acceptable

level of accuracy. In p articular, benchmarks are very good at d etermining the actua l

I/ O requiremen ts and testing recovery processes when a system is fully loaded .

Benchmarks by their nature stress all system comp onents to th eir limits. As all

compon ents are being stressed be p repared to see all errors in app lication design

and implementation manifest themselves while benchm arking. Benchmarks also

test database, operating system, and h ardware comp onents. Because most

benchmarks are performed in a ru sh, expect setbacks and p roblems when a systemcomponent fails. Benchmarking is a stressful activity, and it takes considerable

experience to get the most ou t of a benchmarking exercise.



37/66


Application Modeling

Modeling the ap plication can ran ge from complex math ematical modeling exercisesto the classic simp le calculations performed on th e back of an envelope. Both

methods h ave merit, with one attemp ting to be very precise and the other making

gross estimates. The down side of both method s is that th ey do not allow for

imp lementation errors and inefficiencies.

The estimation an d sizing process is an imp recise science. However, by

investigating the p rocess, some intelligent estimates can be m ade. The whole

estimation process makes no allowances for application inefficiencies introduced by

writing bad SQL, poor index design, or poor cur sor managemen t. A good sizing

engineer bu ilds in margin for application inefficiencies. A good p erformance

engineer d iscovers the inefficiencies and makes the estima tes look realistic. The

process of discovering the app lication inefficiencies is described in th e Oracle

performance method.

Testing, Debugging, and Validating a DesignThe testing process mainly consists of functional and stability testing. At some point

in the p rocess, performance testing is performed .

The following list describes some simple ru les for performance testing an

app lication. If correctly docum ented , this provid es importan t information for the

prod uction app lication and the capacity planning p rocess after the app lication has

gone live.

s

Test with realistic da ta volum es and distributions.All testing must be done w ith fully pop ulated t ables. The test database should

contain data representative of the prod uction system in terms of da ta volume

and cardinality between tables. All the produ ction indexes should be built and

the schema statistics shou ld be p opu lated correctly.

s Use the correct optimizer mod e.

All testing should be performed w ith the optimizer mod e that w ill be used in

prod uction. All Oracle research and d evelopmen t effort is focused u pon thecost-based op timizer, and th erefore Oracle Corporation recomm ends the use of

the cost-based optimizer.

s Test a single u ser performance.

A single user on an id le or lightly used system should be tested for acceptable

performance. If a single user cannot get acceptable performance under id eal



38/66


conditions, it is impossible there will be good performan ce und er mu ltiple users

where resources are shared .

s Obtain and docum ent plans for all SQL statements.

Obtain an execution p lan for each SQL statement, and some m etrics should be

obtained for at least one execution of the statement. This process shou ld be used

to validate that a good execution plan is being obtained by the optimizer and

the relative cost of the SQL statement is und erstood in term s of CPU time an d

physical I/ Os. This process assists in identifying the heavy use transactions that

will require the most tun ing and performance work in the future.

s Attempt mu ltiuser testing.

This process is difficult to p erform accurately, because u ser workload and

profiles might not be fully quantified. How ever, transactions performing DML

statements shou ld be tested to ensu re that there are no locking conflicts or

serialization p roblems.

s Test with the correct hardw are configu ration.

It is important to test with a configuration as close to the prod uction system as

possible. This is par ticularly imp ortant with respect to netw ork latencies, I/ O

sub-system band width and processor type an d speed. A failure to do th is could

result in an incorrect analysis of potential performan ce problems.

s Measure steady state performance.

When benchmarking, it is important to m easure the performance under steady

state conditions. Each benchmark run should h ave a ram p-up phase, where

users are connected to the app lication and gradually start performing work on

the app lication. This process allows for frequently cached da ta to be initialized

into the cache and single execution operat ions, such as p arsing, to be completed

prior to the steady state condition. Likewise, at the end of a benchm ark ru n,

there should be a ram p-down period, where resources are freed from the

system an d users cease work an d disconnect.

Deploying New Applications


39/66



This section d escribes design d ecisions involved d eploying ap plications.

Rollout StrategiesWhen new ap plications are rolled out, two strategies are comm only adop ted:

s Big Bang App roach - All users m igrate to the new system at once.

s Trickle Approach - Users slowly m igrate from existing systems to the new one.

Both ap proaches have m erits and disadvantages. The Big Bang ap proach relies on

good testing of the application at the required scale, but h as the advantage of

minim al data conversion and synchronization with th e old system, because it is

simply switched off. The Trickle approach allows debugging of scalability issues as

the w orkload increases, but might m ean that d ata needs to be migrated to and from

legacy systems as th e transition takes p lace.

It is hard to recommend one app roach over the other, because each method h as

associated risks that could lead to system outages as th e transition takes place.Certainly, the Trickle app roach allows p rofiling of real users as th ey are introd uced

to the new app lication and allows the system to be reconfigured on ly affecting the

migrated users. This app roach affects the work of the early adopters, but limits the

load on su pp ort services. This mean s that u nschedu led outages only affect a small

percentage of the user pop ulation.

The decision on how to roll out a new app lication is specific to each bu siness. The

app roach adop ted w ill have its own un ique pressures and stresses. The more testingand know ledge derived from the testing p rocess, the more you will realize what is

best for the rollout.

Performance ChecklistTo assist in the rollout process, build a list of tasks that, if performed correctly,

increase the chance of good p erformance in prod uction and , if there is a problem,

enable rapid d ebugging of the app lication. For example:

1. When you create the control file for the produ ction d atabase, allow for growth

by setting MAXINSTANCES, MAXDATAFILES, MAXLOGFILES, MAXLOGMEMBERS,

an d MAXLOGHISTORY to values higher than wh at you an ticipate for the rollout.

This results in more d isk space usage and bigger control files, but saves time

later should th ese need extension in an emergency.



40/66


2. Set block size and optimizer mod e to that used to d evelop the app lication.

Export th e schema statistics from the developm ent/ test environm ent to the

prod uction database if the testing was done on representative data volum es andthe cur rent SQL execution p lans are correct.

3. Set the minimal nu mber of initialization parameters. The important param eters

to set size the various caches within the SGA. The add itional pa rameters that

specify the behav ior of the archive du mp destinations shou ld be set for backup

and debu gging pu rposes. Ideally, most other param eters should be left at

default. If there is more tuning to perform, this shows up w hen the system is

und er load.

4. Be prepared to m anage block contention by setting storage options of database

objects. Tables and indexes that experience high INSERT/UPDATE/DELETErates should be created with either au tomatic segment space man agement or

mu ltiple freelists and an increased setting ofINITRANS. To avoid contention of

rollback segments, either automatic undo managem ent should be used or

mu ltiple rollback segmen ts should be created to sup port the required user

population.

5. All SQL statements shou ld be verified to be opt imal and their resource usage

understood.

6. Validate that midd leware an d programs that connect to the database are

efficient in their connection managem ent and do n ot logon/ logoff repeated ly.

7. Validate tha t the SQL statemen ts use cursors efficiently. Each SQL statem ent

should be p arsed once and then executed mu ltiple times. The most comm on

reason this does not happen is because bind variables are not used p roperly and

WHERE clause pred icates are sent as string literals. If the p recomp ilers are u sed

to develop the ap plication, then m ake sure that the p arameters

MAXOPENCURSORS, HOLD_CURSOR, and RELEASE_CURSOR have been reset

from the default values pr ior to precomp iling the app lication.


for guidance on setting m inimal parameters in initial instance

configuration

See Also: Oracle9i Database Administrators Guide for more

information on using automatic undo m anagement and on

managing free space w ith autom atic segment space management



41/66


8. Validate that all schema objects have been correctly migrated from the

developm ent environment to the produ ction database. This includ es tables,

indexes, sequences, triggers, packages, procedures, functions, java objects,

synonym s, grants, and views. Ensure that any modifications made in testing are

mad e to the produ ction system.

9. As soon as the system is rolled ou t, establish a baseline set of statistics from th e

database and operating system. To do th is, use Enterpr ise Manager or

Statspack. This first set of statistics validates or corrects any assumptions mad e

in the design and rollout p rocess.

10. Start an ticipating the first bottleneck (there will always be one) and follow th e

Oracle performance method to m ake performance imp rovement.



42/66



43/66

Monitoring and Improving Application Performance 2-1

2Monitoring and Improving Application

Performance

This chap ter contains th e following sections:

s Importance of Statistics

s

The Oracle Performance Imp rovemen t Method

Importance of Statistics


44/66



Before reacting to a problem, collect all possible statistics and get an overall pictureof the app lication. Getting a comp lete land scape of the system m ay take

considerable effort. But, if data has already been collected and embed ded into the

app lication,thenth isprocessismu ch easier.

After collecting as m uch initial da ta as p ossible, outline issues found from the

statistics, the same way d octors collect symptoms from patients. Reacting to

symp toms too early in the performance analysis process generally results in an

incorrect analysis, which wastes time later. For example, it is extremely risky for a

doctor to prescribe open h eart surgery for a patient wh o comp lains of chest pains

on th e initial consultation.

Operating System Statistics

Operating system statistics provide information on the usage and performance of

the main hard ware comp onents of the system, as well as the performance of the

operating system itself. This information is crucial for detecting p otential resource

exhaustion, such as CPU cycles and p hysical mem ory, and for detecting badperformance of peripherals, such as d isk drives.

Operating system statistics are only an indication of how the hard ware and

operating system are w orking. Many system performan ce analysts react to a

hard ware resource shortage by installing m ore hardware. This is a reactionary

response to a series of symp toms show n in th e operating system statistics. It is

always best to consid er operating system statistics as a diagnostic tool, similar to the

way m any d octors use body temp erature, pu lse rate, and patient pain wh en makinga d iagnosis. To help id entify bottlenecks, gather operating system statistics for all

servers in the system under p erformance analysis.

Operating system statistics include the following:

s CPU Statistics

s Virtual Memory Statistics

s Disk Statisticss Network Statistics

CPU Statistics CPU utilization is the most important op erating system statistic in thetun ing process. Get CPU utilization for the entire system and for each ind ividua l

CPU on mu lti-processor environm ents. Utilization for each CPU can d etect

single-thread ing an d scalability issues.



45/66

Monitoring and Improving Application Performance 2-3

Most operating systems report CPU usage as time spent in u ser space or mode and

time spen t in kernel space or m ode. These add itional statistics allow better analysis

of what is actually being executed on the CPU.

On an Oracle data server system, wh ere there is generally only one app lication

run ning, the server run s database activity in u ser space. Activities required to

service da tabase requests (such as sched uling, synchronization, I/ O, m emory

managem ent, and p rocess/ thread creation and tear dow n) run in kernel mod e. In a

system w here all CPU is fully utilized, a healthy Oracle system run s between 65%

and 95% in u ser space.

Virt

Performance_PLaning

Documents

Transcript of Performance_PLaning