Designing and Developing For Performance

3
Designing and Developing

for Performance
Copyright © 2004, Oracle. All rights reserved.

Objectives
After completing this lesson, you should be able to

describe the basic steps involved in designing and
developing for performance.
3-2 Copyright © 2004, Oracle. All rights reserved.
Objectives
After completing this lesson, you should be able to:
• Understand scalability
• Tune for single-user versus multiuser environments
• Balance multiple applications
• Determine OLAP requirements versus OLTP requirements
• Employ proactive tuning methodologies
• List application design principles
• Use dynamic SQL in application development
• List the benefits of bind variables and writing SQL to share cursors
• Describe the steps for implementing and testing
• List the trends in application development
• Compare rollout strategies
• Use a performance checklist
Oracle Database 10g: SQL Tuning Workshop 3-2

Understanding Scalability
• Scalability is a system’s ability to process more

workload, with a proportional increase in system
resource use.
• Poor scalability leads to system resource
exhaustion to the extent that additional
throughput is impossible when the system’s
workload is increased.
Understanding Scalability
Scalability is a system's ability to process additional workload, with a proportional increase in
system resource use. In other words, if you double the workload in a scalable system, then the
system must use twice as many system resources. However, while some resource utilization may
increase in proportion to the scale up, other resources may scale differently depending on the
resource in question and the application use.
Examples of bad scalability due to resource conflicts include the following:
• Applications requiring significant concurrency management as user populations increase
• Increased data consistency workload
• Increased operating system workload
• Transactions requiring increases in data access as data volumes increase
• Poor SQL and index design, resulting in a higher number of logical I/Os for the same
number of rows returned
• Reduced availability because database objects take longer to maintain

Scalability with Application Design,
Implementation, and Configuration
Applications have a significant impact on scalability.

• Poor schema design can cause expensive SQL
that does not scale.
• Poor transaction design can cause locking and
serialization problems.
• Poor connection management can cause
unsatisfactory response times and unreliable
systems.
Scalability with Application Design, Implementation, and Configuration

Poor application design, implementation, and configuration have a significant impact on
scalability.
However, the design is not the only problem. The physical implementation of the application can
be the weak link, as in the following examples:
• Systems can move to production environments with poorly written SQL that are causing
high I/O.
• Infrequent transaction COMMITs or ROLLBACKs can cause locks on resources.
• The production environment could use different execution plans than those generated in
testing.
• Memory-intensive applications that allocate a large amount of memory without much
thought for freeing the memory can cause excessive memory leakage.
• Inefficient memory usage and memory leaks put a high stress on the operating virtual
memory subsystem. This affects performance and availability.

Configuring the Appropriate System
Architecture for Your Requirements
• Interactive applications (OLTP)

• Process-driven applications (OLAP)
Configuring the Appropriate System Architecture for Your Requirements

Configuring the initial system architecture is a largely iterative process. Architects must satisfy
the system requirements within budget and schedule constraints. If the system requires
interactive users to transact business or make decisions based on the contents of a database, then
user requirements drive the architecture. If there are few interactive users on the system, then the
architecture is process driven. Process-driven applications draw from the skill sets that are used
in both user-based applications and data warehousing.
Some of the things to consider are:
• Number of users (Web application versus few users)
• User interaction method (query versus transaction)
• User location (LAN versus WAN)
• Network speed
• Amount of read-only data (query versus DML)
• User response-time requirement
• 24/7 operation (high availability)
• Real-time changes (OLTP)
• Size of database

Proactive Tuning Methodology
• Simple design
• Data modeling
• Tables and indexes
• Using views
• Writing efficient SQL
• Cursor sharing
• Using bind variables
• SQL versus PL/SQL
• Dynamic SQL
Proactive Tuning Methodology

Tuning usually implies fixing a performance problem. However, tuning should be part of the life
cycle of an application, through the analysis, design, coding, production, and maintenance
stages. The tuning phase is frequently left until the system is in production. At such a time,
tuning becomes a reactive exercise, where the most important bottleneck is identified and fixed.
The slide lists some of the things that affect performance and that should be tuned proactively
instead of reactively. These are discussed in more detail in the following slides.

Simplicity In Application Design
• Simple tables
• Well-written SQL
• Indexing only as required
• Retrieving only required information
Simplicity in Application Design

Applications are no different than any other designed and engineered product. If the design looks
right, then it probably is right. This principle should always be kept in mind when building
applications. Consider some of the following design issues:
• If the table design is so complicated that nobody can fully understand it, the table is
probably designed badly.
• If SQL statements are so long and involved that it would be impossible for any optimizer to
effectively optimize it in real time, then there is probably a bad statement, underlying
transaction, or table design.
• If there are many indexes on a table and the same columns are repeatedly indexed, there is
probably a bad index design.
• If queries are submitted without suitable qualification (WHERE clause) for rapid response
for online users, there is probably a bad user interface or transaction design.

Data Modeling
• Accurately represent business practices

• Focus on the most frequent and important
business transactions
• Use modeling tools
• Normalize the data
Data Modeling
Data modeling is important in successful relational application design. This should be done in a
way that quickly and accurately represents the business practices. Apply your greatest modeling
efforts to those entities affected by the most frequent business transactions. Use of modeling
tools can then rapidly generate schema definitions and can be useful when a fast prototype is
required.
Normalizing data prevents duplication. When data is normalized, you have a clear picture of the
keys and relationships. It is then easier to perform the next step of creating tables, constraints,
and indexes. A good data model ultimately means that your queries will be written more
efficiently.

Table Design
• Compromise between flexibility and performance

– Principally normalize
– Selectively denormalize
• Use Oracle performance features
– Default values
– Check constraints
– Materialized views
– Clusters
• Focus on business-critical tables
Table Design
Table design is largely a compromise between flexibility and performance of core transactions.
To keep the database flexible and able to accommodate unforeseen workloads, the table design
should be very similar to the data model, and it should be normalized to at least third normal
form. However, certain core transactions required by users can require selective denormalization
for performance purposes.
Use the features supplied with Oracle Database 10g to simplify table design for performance,
such as storing tables prejoined in clusters, the addition of derived columns, aggregate values,
and using materialized views. Additionally, create check constraints and columns with default
values to prevent bad data from getting into the tables.
Design should be focused on business-critical tables so that good performance can be achieved
in areas that are the most used. For noncritical tables, shortcuts in design can be adopted to
enable a more rapid application development. If, however, a noncore table becomes a
performance problem during prototyping and testing, then remedial design efforts should be
applied immediately.

Index Design
• Index keys
– Primary key
– Unique key
– Foreign keys
• Index data that is frequently queried
• Use SQL as a guide to index design
Index Design
Index design is also a largely iterative process, based on the SQL that is generated by application
designers. However, it is possible to make a sensible start by building indexes that enforce
foreign key constraints (to reduce response time on joins between primary key tables and foreign
key tables) and creating indexes on frequently accessed data, such as a person's name. Primary
keys and unique keys are automatically indexed. As the application evolves and testing is
performed on realistic sizes of data, certain queries will need performance improvements, for
which building a better index is a good solution.
The following indexing design ideas should be considered when building a new index.
Appending Columns to an Index or Using Index-Organized Tables
One of the easiest ways to speed up a query is to reduce the number of logical I/Os by
eliminating a table scan from the execution plan. This can be done by appending to the index all
columns referenced by the query. These columns are the select list columns and any required
join or sort columns. This technique is particularly useful in speeding up an online application’s
response times when time-consuming I/Os are reduced. This is best applied when testing the
application with properly sized data for the first time.

Index Design (continued)
Using a Different Index Type
The most aggressive form of this technique is to build an index-organized table (IOT).
There are several index types available, and each index has benefits for certain situations.
• B*tree index: This is the standard index type and the default when other types are not
specified. Used as concatenated indexes, B-tree indexes can be used to retrieve data sorted
by the index columns.
• Bitmap index: This is suitable for low-cardinality data. Combining bitmap indexes on
nonselective columns allows efficient AND and OR operations with a great number of row
IDs with minimal I/O. Bitmap indexes are particularly efficient in queries with COUNT(),
because the query can be satisfied within the index.
• Function-based index: Function-based indexes are particularly useful when querying on
composite columns to produce a derived result or to overcome limitations in the way data
is stored in the database. For example, you may search for orders in which an expression
such as (sales price – discount) * quantity exceeds a given value (assuming these are
columns in the table). Another example is to apply the function to the data to allow case-
insensitive searches (UPPER or LOWER).
• Reverse key index: These indexes are excellent for insert performance, but they are
limited in that they cannot be used for index range scans. Use of sequences, or time stamps,
to generate key values that are indexed themselves can lead to database hotspot problems
due to a monotonically growing key, which affects response time and throughput.
Generating keys that insert over the full range of the index results in a well-balanced index
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.
Cost of an Index
Building and maintaining an index structure can be expensive, and it can consume resources
such as disk space, CPU, and I/O capacity. You must ensure that the benefits of any index
outweigh the negatives of index maintenance.
Use this simple estimation guide for the cost of index maintenance: Each index maintained by an
INSERT, DELETE, or UPDATE of the indexed keys requires about three times as many
resources as the actual DML operation on the table. What this means is that if you INSERT into
a table with three indexes, then it will be approximately 10 times slower than an INSERT into a
table with no indexes. For DML, and particularly for INSERT-heavy applications, the index
design should be seriously reviewed, which might require a compromise between the query and
INSERT performance.
Ordering Columns in an Index
You should be flexible in defining any rules for index building. Order columns that have the
most selectivity first. This method is the most commonly used because it provides the fastest
access with minimal I/O to the actual row IDs required. This technique is used mainly for
primary keys and for very selective range scans. You can also place the most frequently used
column first so that the index is beneficial to several queries.

Using Views
• Simplifies application design

• Is transparent to the end user
• Can cause suboptimal execution plans
Using Views
Views can speed up and simplify application design. A simple view definition can mask data
model complexity from the programmers whose priorities are to retrieve, display, collect, and
store data.
However, while views provide clean programming interfaces, they can cause suboptimal,
resource-intensive queries when nested too deeply. The worst type of view use is creating joins
on views that reference other views, which in turn reference other views. In many cases,
developers can satisfy the query directly from the table without using a view. Because of their
inherent properties, views usually make it difficult for the optimizer to generate the optimal
execution plan.

SQL Execution Efficiency
• Good database connectivity

• Using cursors
• Minimizing parsing
• Using bind variables
SQL Execution Efficiency

An application that is designed for SQL execution efficiency must support the following
characteristics:
Good database connection management: Connecting to the database is an expensive operation.
Therefore, the number of concurrent connections from each client to the database should be
minimized. However, in a Web-based or multitiered application where application servers are
used to multiplex database connections to users, this can be difficult. Design efforts should
ensure that database connections are pooled and are not reestablished for each user request.
Good cursor usage and management: Parsing should be minimized as much as possible.
Applications should be designed to parse SQL statements once and execute them many times.
Use bind variables to represent the parts of the query that change from execution to execution. If
this is not done, then the SQL statement is likely to be parsed once and never reused by other
users. To ensure that SQL is shared, use bind variables and do not use string literals with SQL
statements.

Importance of Sharing Cursors
• Reduces parsing
• Dynamically adjusts memory
• Improves memory usage
Importance of Sharing Cursors

When a SQL statement is found in the shared SQL area, then the parse phase is shortened and
the existing cursor is used. The following are the main benefits of sharing cursors:
• Sharing cursors reduces parsing and saves time.
• Memory dynamically adjusts to the SQL being executed because the same area of library
cache can be reused.
• Memory usage may improve dramatically, even for tools that store SQL within the
application.

Writing SQL to Share Cursors
• Create generic code using the following:

– Stored procedures and packages
– Database triggers
– Any other library routines and procedures
• Write to format standards:
– Case
– White space
– Comments
– Object references
– Bind variables
Writing SQL to Share Cursors

In order for Oracle to share cursors, the code must be written exactly the same. You should
therefore develop coding conventions for SQL statements in ad hoc queries, SQL scripts, and
Oracle Call Interface (OCI) calls.
Use generic shared code:
• Write and store procedures that can be shared across applications.
• Use database triggers.
• Write referenced triggers and procedures when using application development tools.
• Write library routines and procedures in other environments.
Write to format standards:
• Develop format standards for all statements, including those in PL/SQL code.
• Develop rules for use of uppercase and lowercase characters.
• Develop rules for use of white space (spaces, tabs, returns).
• Develop rules for use of comments (preferably keeping them out of the SQL statements
themselves).
• Use the same names to refer to identical database objects.

Controlling Shared Cursors
The CURSOR_SHARING initialization parameter can be

set to:
• EXACT (default)
• SIMILAR (not recommended)
• FORCE
Controlling Shared Cursors

One of the first stages of parsing is to compare the text of the statement with existing statements
in the shared pool to see if the statement can be shared. If the statement differs textually in any
way, then the Oracle Database does not share the statement. Exceptions to this are possible using
the CURSOR_SHARING parameter. Setting CURSOR_SHARING to EXACT allows SQL
statements to share the SQL area only when their texts match exactly. This is the default
behavior. Using this setting, similar statements cannot be shared; only textually exact statements
can be shared.
Setting CURSOR_SHARING to either SIMILAR or FORCE allows similar statements to share
SQL. The difference between SIMILAR and FORCE is that SIMILAR forces similar statements
to share the SQL area without deteriorating execution plans. Setting CURSOR_SHARING to
FORCE forces similar statements to share the executable SQL area, potentially deteriorating
execution plans. Hence, SIMILAR and FORCE should be used as a last resort, when the risk of
suboptimal plans is outweighed by the improvements in cursor sharing.
Example:
SQL> ALTER SESSION SET CURSOR_SHARING ='EXACT';

Performance Checklist
• Set initialization parameters and storage options.

• Verify resource usage of SQL statements.
• Validate connections by middleware.
• Verify cursor sharing.
• Validate migration of all required objects.
• Verify validity and availability of optimizer
statistics.
Performance Checklist
• Set the minimal number of initialization parameters. Ideally, most initialization parameters
should be left at default. If there is more tuning to perform, this shows up when the system
is under load. Set storage options for tables and indexes in appropriate tablespaces.
• Verify that all SQL statements are optimal and understand their resource usage.
• Validate that middleware and programs that connect to the database are efficient in their
connection management and do not log on and log off repeatedly.
• Validate that the SQL statements use cursors efficiently. Each SQL statement should be
parsed once and then executed multiple times. The most common reason this does not
happen is because bind variables are not used properly and WHERE clause predicates are
sent as string literals.
• Validate that all schema objects have been correctly migrated from the development
environment to the production database. This includes tables, indexes, sequences, triggers,
packages, procedures, functions, Java objects, synonyms, grants, and views. Ensure that
any modifications made in testing are made to the production system.
• As soon as the system is rolled out, establish a baseline set of statistics from the database
and operating system. This first set of statistics validates or corrects any assumptions made
in the design and rollout process.

Summary
In this lesson, you should have learned the basic steps

that are involved in designing and developing for
performance.
Summary
In this lesson, you should have learned how to:
• Understand scalability
• Tune for single-user versus multiuser environments
• Balance multiple applications
• Determine OLAP requirements versus OLTP requirements
• Employ proactive tuning methodologies
• List application design principles
• Use dynamic SQL in application development
• List the benefits of bind variables and writing SQL to share cursors
• Describe steps in implementing and testing
• List the trends in application development
• Compare rollout strategies
• Use a performance checklist

Practice 3: Overview
This practice covers understanding the use of shared

cursors.

Designing and Developing For Performance

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Designing and Developing For Performance

Uploaded by

Copyright:

Available Formats

3

Designing and Developing

Copyright © 2004, Oracle. All rights reserved.

After completing this lesson, you should be able to

3-2 Copyright © 2004, Oracle. All rights reserved.

Oracle Database 10g: SQL Tuning Workshop 3-2

• Scalability is a system’s ability to process more

3-3 Copyright © 2004, Oracle. All rights reserved.

Oracle Database 10g: SQL Tuning Workshop 3-3

Applications have a significant impact on scalability.

3-4 Copyright © 2004, Oracle. All rights reserved.

Scalability with Application Design, Implementation, and Configuration

Oracle Database 10g: SQL Tuning Workshop 3-4

• Interactive applications (OLTP)

3-5 Copyright © 2004, Oracle. All rights reserved.

Configuring the Appropriate System Architecture for Your Requirements

Oracle Database 10g: SQL Tuning Workshop 3-5

3-6 Copyright © 2004, Oracle. All rights reserved.

Proactive Tuning Methodology

Oracle Database 10g: SQL Tuning Workshop 3-6

3-7 Copyright © 2004, Oracle. All rights reserved.

Simplicity in Application Design

Oracle Database 10g: SQL Tuning Workshop 3-7

• Accurately represent business practices

3-8 Copyright © 2004, Oracle. All rights reserved.

Oracle Database 10g: SQL Tuning Workshop 3-8

• Compromise between flexibility and performance

3-9 Copyright © 2004, Oracle. All rights reserved.

Oracle Database 10g: SQL Tuning Workshop 3-9

3-10 Copyright © 2004, Oracle. All rights reserved.

Oracle Database 10g: SQL Tuning Workshop 3-10

Oracle Database 10g: SQL Tuning Workshop 3-11

• Simplifies application design

3-12 Copyright © 2004, Oracle. All rights reserved.

Oracle Database 10g: SQL Tuning Workshop 3-12

• Good database connectivity

3-13 Copyright © 2004, Oracle. All rights reserved.

SQL Execution Efficiency

Oracle Database 10g: SQL Tuning Workshop 3-13

3-14 Copyright © 2004, Oracle. All rights reserved.

Importance of Sharing Cursors

Oracle Database 10g: SQL Tuning Workshop 3-14

• Create generic code using the following:

3-15 Copyright © 2004, Oracle. All rights reserved.

Writing SQL to Share Cursors

Oracle Database 10g: SQL Tuning Workshop 3-15

The CURSOR_SHARING initialization parameter can be

3-16 Copyright © 2004, Oracle. All rights reserved.

Controlling Shared Cursors

Oracle Database 10g: SQL Tuning Workshop 3-16

• Set initialization parameters and storage options.

3-17 Copyright © 2004, Oracle. All rights reserved.

Oracle Database 10g: SQL Tuning Workshop 3-17

In this lesson, you should have learned the basic steps

3-18 Copyright © 2004, Oracle. All rights reserved.

Oracle Database 10g: SQL Tuning Workshop 3-18

This practice covers understanding the use of shared

3-19 Copyright © 2004, Oracle. All rights reserved.

Oracle Database 10g: SQL Tuning Workshop 3-19

You might also like