Oracle Architecture and Design Issues for E-Business

This chapter is from the book

e-Business for the Oracle DBA

Learn More Buy

This chapter is from the book

This chapter is from the book 

e-Business for the Oracle DBA

Learn More Buy

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 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:

• Disk drives—Consider using a Redundant Array of Inexpensive Disks (RAID) configuration.

• 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.

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.

Listing 3.1 Determining the Average I/O by Hour of the Day

Set pages 9999;
Column phyreads format 999,999,999
Column phywrites format 999,999,999
Select
To_char(snap_time, 'HH24'),
Avg(physical_reads) phyreads,
Avg(physical_writes) phywrites
From
Perfstat.stats$buffer_pool_statistics bp,
Perfstat.stats$snapshot sn,
Where
Bp.snap_id = sn.snap_id
Group by
To_char(snap_time, 'HH24');

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:

Listing 3.2 Setting Alerts

Set pages 9999;
Set feedback off;
Set verify off;
Prompt ****************************************
Prompt When the buffer cache hit rate is < 85%,
Prompt you should consider increasing the
Prompt db_block_buffers parameter
Prompt ****************************************
Column "BUFFER HIT RATIO" format 999
Select
To_char(snap_time, 'yyyy-mm-dd HH24'),
Round(100*((a.value+b.value)-c.value)/(a.value+B.value)) "BUFFER HIT RATIO"
From
Perfstat.stats$sysstat a,
Perfstat.stats$sysstat b,
Perfstat.stats$sysstat c,
Perfstat.stats$sysstat d,
Perfstat.stats$snapshot s
Where
(round(100*((a.value+b.value)-c.value)/(a.value+b.value))) < 85 and
snap_time > sysdate-&1 and
a.snap_id = s.snap_id and
b.snap_id = s.snap_id and
c.snap_id = s.snap_id and
d.snap_id = s.snap_id and
a.statistic# = 39 and
b.statistic# = 38 and
c.statistic# = 40 and
d.statistic# = 41;
Prompt ******************************************************
Prompt When the I/O wait is very high,
Prompt it indicates disk contention and you should consider
Prompt reshuffling of datafiles to remove the contention
Prompt *****************************************************
Column snapdate format a16
Column filename format a40
Select
To_char(snap_time,'yyyy-mm-dd HH24') snapdate,
Filename,
Wait_count
From
Perfstat.stats$filestatxs f,
Perfstat.stats$snapshot s
Where
Snap_time > sysdate-&1 and
f.snap_id = s.snap_id and
wait_count > 2000;