Home > Articles > Data > Oracle

Oracle Architecture and Design Issues for E-Business

  • Print
  • + Share This
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

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:

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

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.

    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
    To_char(snap_time, 'HH24'),
    Avg(physical_reads) phyreads,
    Avg(physical_writes) phywrites
    Perfstat.stats$buffer_pool_statistics bp,
    Perfstat.stats$snapshot sn,
    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:

    Buffer hit ratio < 85%
    I/O waits > 2000

    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
    To_char(snap_time, 'yyyy-mm-dd HH24'),
    Round(100*((a.value+b.value)-c.value)/(a.value+B.value)) "BUFFER HIT RATIO"
    Perfstat.stats$sysstat a,
    Perfstat.stats$sysstat b,
    Perfstat.stats$sysstat c,
    Perfstat.stats$sysstat d,
    Perfstat.stats$snapshot s
    (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
    To_char(snap_time,'yyyy-mm-dd HH24') snapdate,
    Perfstat.stats$filestatxs f,
    Perfstat.stats$snapshot s
    Snap_time > sysdate-&1 and
    f.snap_id = s.snap_id and
    wait_count > 2000;
    • + Share This
    • 🔖 Save To Your Account