This sample chapter from e-Business for the Oracle DBA covers capacity planning, using StatsPack for capacity planning purposes, architectural issues and components of an e-Business, and design issues for e-Businesses.

This chapter is from the book

Capacity Planning, Architecture, and Design Issues Essentials

Proper capacity planning can minimize performance problems in the system
after it is implemented.

Capacity planning for an e-Business is an art rather than a science because
its requirements change all the time.

Oracle8i (release 8.1.6) and higher provide a mechanism called the
STATSPACK utility for historical data collection and the capability to translate
the data into reports that can show database usage trends.

One key characteristic of a successful e-Business is its capability and
willingness to change quickly according to market needs. An even better
characteristic is its capability to predict the direction in which the market
might shift in the future so that it can prepare in advance to meet the new
demands.

The e-Business architecture is better than a straight client/server
architecture because the client doesn't stay connected to the database, the
application server stays connected only for the time required to make a request
and receive the results back from the database server, network traffic is
reduced, idle processes do not consume resources, and response time is
improved.

When you start to move your systems to an e-Business, it can help to start
small and identify a small project that can quickly make the transition and at
the same time provide high impact and return on investment (ROI). When this
transition is successful, you can build on the experience and feedback from this
venture.

An e-Business needs to have a forward-looking application architecture that
deals with the following critical requirements:

Easy-to-use interface

Integration of intra-business processes

Innovative methods for adding value

Customer- and solution-oriented procedure

Plan for growth and change

In this chapter, we will do the following:

Learn how to perform capacity planning

Learn how to use StatsPack for capacity planning purposes

Examine architectural issues for an e-Business

Examine the architectural components

Look at design issues for e-Businesses

Capacity Planning

Capacity planning is part of the planning phase. This very important process
is completed with the intention of minimizing performance problems with the
system after it is implemented. In this sense, capacity planning involves
analyzing the same kinds of issues that you would analyze when tuning the
system:

How should you choose the system components to use?

What type of architecture is suitable?

What values should be set for the various parameters?

What are the characteristics of the applications?

What are the characteristics of the system?

What business rules are to be implemented?

How much can be forecasted or predicted about the system usage?

What are the system requirements in terms of availability? Scalability?
Security? Performance?

Capacity Planning

Good capacity planning provides a cushion for sudden bursts in load and can
tolerate some application inefficiencies.

Capacity planning for an e-Business is an art rather than a science because
its requirements change all the time. Its characteristics also change all the
time and are difficult to predict. To understand the capacity planning issues
with an e-Business such as DOeBIZ.com, you have to understand that it is very
difficult in such an environment to have a satisfactory architecture that meets
all the requirements well. You should plan for possible extra growth and build a
system that has more capacity than current and predicted future needs.

Capacity Planning Questions

Several important questions need to be addressed as part of the capacity
planning process:

What are the scalability requirements? Scalability is the ability
to gracefully enhance the capacity of the system to support a greater system
load. The architecture you choose should enable you to easily do the
following:

Add more hardware to increase capacity (instead of completely reworking
the system)

Upgrade the operating system to take advantage of the new
hardware

Redistribute the load to take advantage of the new system
configuration

Generally, scalability is determined in terms of the performance
increase relative to additional system components; for example, if one CPU gives
a performance of x and adding an extra CPU gives a performance of
1.4x, the scalability is 1.4. This increase is not usually linear because
of the overhead associated with coordinating the activity of the additional
components. Good capacity planning requires a good understanding of future
needs. If you improperly predict future needs, you might be able to satisfy your
immediate system needs, but fixing problems due to unforeseen increases or
changes of needs would require a lot of effort.

What are the availability requirements? Availability requirements
are generally specified as the percentage of time that your system has to be up.
Transaction processing e-Commerce sites usually have very high availability
requirements. The Internet itself has a reliable built-in capability to route
around problems; therefore, when you're looking at high availability
solutions, you should look at these elements of your own system:

Web server hardwarePCs are cheap but not very reliable,
whereas mainframes are extremely reliable but very expensive. Therefore, you
could use workstations as a compromise for the Web server hardware.

Operating systemCompared to Windows and Macintosh, UNIX
systems are much more stable and are better suited for high availability
requirements. You might also consider a high-availability OS such as Solaris
HA.

Uninterruptible power supply (UPS)Using a UPS is a
necessity.

Clustering solutionYou should seriously consider using a
UNIX- or NT-based clustering solution.

Automatic Notification

High availability requirements dictate quick reaction by an iDBA. Therefore,
it is very valuable to have an architecture in place that supports automatic
notification to an iDBA when performance falls below a certain threshold or when
other critical events occur.

What are the budgetary constraints? Money is always an important
issue, and you need to ensure that the chosen architecture can provide a high
benefit-per-cost ratio. You should also consider the budget for ongoing
maintenance and upgrades of the architecture as well as the cost for
administration and performance tuning.

Beware of Bottlenecks

When you add extra components to increase capacity, take care to ensure that
you are not introducing a bottleneck somewhere by virtue of this system
change.

Oracle Database Trend Analysis Using STATSPACK

Proper designing and capacity planning (and later, database tuning) will
benefit tremendously if some trend analysis is available for the database usage.
Oracle8i (release 8.1.6) and higher provides a mechanism called the STATSPACK
utility for historical data collection and the capability to translate the data
into reports that can show the database usage trend. Even though Oracle
introduces STATSPACK with Oracle 8.1.6, a patch available from Oracle
Corporation allows you to use STATSPACK with any Oracle8 database.

The STATSPACK utility is a set of scripts that run a special version of the
Oracle BSTAT/ESTAT utilities. Unlike BSTAT/ESTAT, STATSPACK captures performance
data and stores it in special Oracle tables with names that have the prefix
STATS$. Each STATS$ table is owned by the PERFSTAT user. Note that you can use
the regular SQL*Plus DESCRIBE command to determine the columns in the
STATS$ table.

DBAs commonly use trend analysis to understand the behavior of the database
at various times. This type of analysis also helps in identifying patterns of
behavior in terms of database usage. Oracle Enterprise Manager (OEM) provides a
capacity planning tool as well, but STATSPACK provides a large number of
statistics that can be used to generate different types of trend reports. Here
are some useful metrics:

Data buffer hit ratioThis metric gives an idea of the
effectiveness of the database buffer cache and the setting of the
db_block_buffers parameter.

Physical disk reads and physical disk writesThese metrics
give a good idea about the I/O activity in the system.

I/O waitsThis metric can be used to determine I/O contention
problems and can indicate whether the physical design of the database is
good.

SortsThis metric is an indication of the effectiveness of
sort activity.

Buffer busy waitsThis metric is an indication of freelist
contention and can also indicate concurrent UPDATE or INSERT
activity on the same object.

After STATSPACK captures the various performance statistics, you can generate
various trend reports using the data gathered. These trend reports would provide
signatures for various database metrics. For example, you might observe that on
Monday mornings between 8 a.m. and 9 a.m., the I/O activity is extraordinarily
high. This knowledge can help in taking the proper actions. In order to forecast
the database growth trend properly, you must archive and analyze the data that
is collected by any tool such as STATSPACK. The script in Listing 3.1 shows how
to plot the average I/O occurring by hour of the day.

In addition to generating trend reports, you can use queries to generate
customized alerts that indicate to the DBA when certain preset thresholds get
exceeded. The script in Listing 3.2 can be scheduled to run at set intervals to
indicate when the following are true: