chapter 1books.mhprofessional.com/downloads/products/... · 8 oracle high-performance tuning with...

ORACLE Series / Oracle High-Performance Tuning with STATSPACK / Burleson / 3378-3 / Chapter 1Blind Folio 1:3

CHAPTER1

Overviewof Oracle Tuning

P:\010Comp\Oracle8\378-3\ch01.vpWednesday, March 28, 2001 6:30:30 PM

Color profile: Generic CMYK printer profileComposite Default screen

4 Oracle High-Performance Tuning with STATSPACK


Oracle tuning has always been the most difficult area of Oracledatabase management. Because of the flexibility of Oracle, theinternal software is phenomenally complex and there are manyhundreds of causes of Oracle performance problems. The inherentcomplexity of the Oracle database leaves many shops unable to

certify that their database is properly tuned.In addition to the complex nature of the Oracle software, we also have the issue

of the dynamic nature of Oracle applications. An Oracle database is constantlychanging, and it is never exactly the same at any two times. Because of the dynamicnature of tuning an Oracle environment, it is very difficult for the Oracle databaseadministrator to get a handle on what’s going on inside their database. Many peoplewho’ve attempted to tune an Oracle database say that it’s analogous to attemptingto work on a car while it is flying down the highway at 60 miles per hour!

While it may be true that the Oracle databases are in a constant state of flux, thereis a general approach that most Oracle experts use when tuning the Oracle database.It’s very important to take a top-down approach to tuning Oracle databases, such thatyou start at a very high level, taking a look at the overall Oracle environment andthen successively drill down into more detail as you begin to tune the individualcomponents within the database engine. For Oracle, the top-down approach meansstarting with the server, drilling down to the instance, drilling down to the objects,and finally examining the Oracle SQL.

The goal of this text is to give you the STATSPACK tools and diagnostic techniquesthat are required to ensure that your Oracle database is performing at an optimal level.While you may not become an Oracle tuning expert from reading this book, you willhave a high-level understanding of the important Oracle tuning issues and know howto run STATSPACK queries to get performance metrics.

The Overall Tuning ApproachWhile there is no silver bullet for tuning Oracle databases, a comprehensive approachto Oracle tuning can help ensure that all of the bases are covered, and that no importanttuning facts have been overlooked. In tuning an Oracle database, you have to startby taking a broad look at the external environment and successively drill down formore details (see Figure 1-1).

The concept of using a drill-down technique is very important to Oracle tuning.We must start at a very broad level, examining the overall environment and lookingcarefully at the database server for any problems that might exist within CPU, RAM,or disk configurations, as shown in Figure 1-2. No amount of tuning is going to helpin an Oracle database when the Oracle database server is short on resources.



Once we’ve completed the tuning of the Oracle server environment, we canthen begin to take a look at the global parameters that affect the Oracle database(the Oracle instance). When looking at the Oracle database, we take a look atthe database as a whole, and we pay careful attention to the Oracle initializationparameters that govern the configuration of the SGA and the overall behavior of thedatabase, as shown in Figure 1-3.

Chapter 1: Overview of Oracle Tuning 5


FIGURE 1-1. The Oracle database tuning hierarchy

FIGURE 1-2. Tuning the Oracle environment



Once the database server in the Oracle instance has been tuned, we can then beginthe work of taking a look at individual Oracle tables and indexes within the database.At this phase, we take a look at the storage settings that can govern the behavior ofa table and take a look at how well the settings accommodate the processing needsof the individual objects (see Figure 1-4).



FIGURE 1-3. Tuning the Oracle instance

FIGURE 1-4. Tuning Oracle objects





Once the Oracle objects are tuned, we then move into tuning the individualSQL queries that are issued against the Oracle database. This is one of the mostchallenging of all of the areas of Oracle tuning because there can be many thousandsof SQL statements issued against a highly active Oracle database. The task for theperson tuning the Oracle SQL is to identify those SQL statements that are used mostfrequently and apply the tools necessary in order to tune each statement for the optimalexecution plan (see Figure 1-5). We will also explore static binding and show howto improve execution by keeping bind plans for the SQL.

In summary, Oracle tuning involves the following steps, with each step beingmore general and broad than the step beneath it:

1. Server, network, and disk tuning If there is a problem with the Oracleserver, such as an overloaded CPU, excessive memory swapping, or diskI/O bottleneck, then no amount of tuning within the Oracle databasesis going to improve your performance. Hence, the first thing the Oracleprofessional examines is the server, disk, and network environment.

FIGURE 1-5. Tuning Oracle SQL





2. Instance tuning The Oracle SGA is tuned, and all of the Oracle initializationparameters are reviewed to ensure that the database has been properlyconfigured. This phase of Oracle tuning is directed at looking for resourceshortages in the db_block_buffers, shared_pool_size, and sort_area_size.We also investigate important default parameters for Oracle such asoptimizer_mode.

3. Object tuning This phase of tuning looks at the setting for Oracle tablesand indexes. Settings such as pctfree, pctused, and freelists can have adramatic impact on Oracle performance, and each object can benefit fromproper storage settings.

4. SQL tuning This is the most time-consuming tuning operation becausethere can be many thousands of individual SQL statements that accessthe Oracle database. At a high level, we identify the most common SQLstatements and tune each statement by carefully reviewing the executionplan for the SQL and adjusting the execution plan using Oracle hints. ForOracle8i, we will also be investigating the new optimizer plan stabilityfeature. Optimizer plan stability allows improved performance by storinga ready-to-go execution plan for SQL statements. We will also see how toimplement optimizer plan stability with the OUTLINE package, so that wecan modify execution plans for specific SQL statements. This is especiallyuseful in cases where you are using vendor-supplied SQL and you cannotchange the SQL source code. For example, in Oracle Applications and SAP,you are not allowed to change the SQL, but with optimizer plan stability youcan tune the SQL by changing the stored execution plan for the SQL.

5. Design tuning The design of the application is the single most importantfactor in Oracle performance. Unfortunately, most Oracle administrators areunable to change a poor design, either because they are using proprietarysoftware or because the design is already implemented in production.

It is critical to the success of your Oracle tuning effort to follow the tuning stepsin their proper order. Many neophyte Oracle DBAs will immediately begin to tuneSQL statements without considering the environment in which the SQL is running.Mistakes like these can often cause problems with the overall tuning effort becausethe broader tuning issues have not yet been identified and corrected.

While later chapters will explore each of these areas in great detail, let’s beginby covering the major areas so that we can understand their impact on Oracleperformance.





Server TuningMany Oracle professionals discount the server environment because they have notbeen trained to understand how the Oracle database interacts with the server. As apracticing Oracle tuning consultant, I have learned that the external environment isthe very first thing an Oracle DBA should take a look at when a performance problemhas been reported. When checking the external server, the Oracle administrator mustcarefully check the settings for the operating system kernel parameters on the databaseserver and carefully monitor the usage of RAM memory and CPU on the database server(see Figure 1-6). If the database server is experiencing disk or network bottlenecks orshortages of hardware resources, no amount of Oracle tuning can alleviate the problem.

Once we understand the basic nature of CPU and memory consumption onthe server, we will turn our attention to extending the STATSPACK utility in orderto capture server information. We will show how the UNIX vmstat utility can beextended in order to capture information regarding the usage on each CPU andmemory within the computer, and to show how this information can be stored insidea STATSPACK table. We will also show how alert reports can then be generated fromthe STATSPACK table, such that the Oracle administrator becomes aware of allserver-related problems that will impact the Oracle database performance.

FIGURE 1-6. Detailed Oracle server tuning



We will also show how this extension of STATSPACK can be used in order tomonitor other servers in an Oracle enterprise environment. We will show how thisremote vmstat collection utility can be used to monitor the behaviors of Web serversand application servers in an Oracle database environment.

Network TuningWith many Oracle databases shared across geographical areas, it is very important forthe Oracle professional to recognize the importance of network communications onthe performance of their databases. As you may know, Oracle provides for distributedcommunications between databases by using its Transparent Network Substrate (TNS).The TNS is a distributed protocol that allows for transparent database communicationsbetween remote systems. The TNS acts as an insulator between Oracle’s logicalrequest for data and the physical communications between the distributed servers.Because of this insulation between the Oracle logical data request and the internalworkings of the network, much of the network performance tuning is in the hands ofthe network administrator. In other words, the Oracle administrator has very little directcontrol over the network configuration settings that can affect the overall performanceof their database (see Figure 1-7).



FIGURE 1-7. Tuning the Oracle network





However, there are some important settings that can be used in order to improvethe performance of distributed transactions. This chapter will take a careful look at theinit.ora parameters that relate to distributed communications, and also take a look atsome of the TCP parameters such as tcp.nodelay, which can be used in order to changethe basic packet-shipping mechanisms within the Oracle database.

We will also take a look at different parameters within the sqlnet.ora, tnsnames.ora,and protocol.ora files, which can be used to change the size and configuration of theTCP packets. These tools can often have a profound impact on the behavior of theunderlying network transport layer and improve throughput of all Oracle transactions.

Disk TuningThe largest single component of Oracle response time is disk I/O (input/output).Anything that the Oracle DBA can do to reduce disk I/O will have a positive benefiton the performance of the database. The reduction of disk I/O is a goal that will bementioned in each of the chapters. For example, changing Oracle initializationparameters can reduce disk I/O and tuning SQL can also greatly reduce disk I/O.

Once we recognize that disk I/O is the single most important factor in tuningany Oracle database, it is understandable that the Oracle DBA needs to fully understandthe internal operations of the disk I/O subsystem. In this day and age of using diskcache storage devises such as EMC, many Oracle DBAs are not always paying carefulattention to the interaction between Oracle database and the disk I/O subsystem (seeFigure 1-8). Another confounding issue is that the disk arrays often have a separateRAM cache, and an I/O request from Oracle does not always translate into a physicaldisk I/O.

FIGURE 1-8. Tuning Oracle disk I/O





Because there are many dozens of ways to configure a disk I/O subsystem,Chapter 8 will focus on all of the common disk placement techniques, the useof RAID, and how the Oracle DBAs can “map” their disks, from the logical mountpoints to the physical disks. Once the mapping between the Oracle datafiles in thephysical disks is clearly understood, the Oracle professional can then move on tocreate tools that will monitor the behavior of the disk I/O subsystem, and relocatefiles to overcome disk I/O bottlenecks.

In keeping with the theme of using STATSPACK, Chapter 8 will show how theOracle DBA can extend the STATSPACK tables in order to capture I/O statistics usingthe generic UNIX iostat utility. Once the iostat utility is in place and constantlymonitoring the behavior of the disk, the Oracle DBAs can create automatedexception reports that will alert them to times when the disk I/O subsystem isundergoing contention.

Chapter 8 also goes into detail on what the Oracle DBA can do to remedydisk I/O bottlenecks and will include discussions on file striping and other RAIDtechniques that are used by the Oracle professional in order to ensure that the loadis evenly balanced among all of the physical disk spindles.

Instance TuningThe concept of instance tuning is one of the most misunderstood areas of Oracletuning. In practice, an overstressed Oracle SGA can cause serious performanceproblems, but once tuned, the Oracle SGA really needs little attention from theOracle professional. This section will show the Oracle DBA how to capture SGAinformation directly from the STATSPACK tables and provide an automated mechanismfor alerting the DBA to shortages within Oracle’s library cache, shared pool, anddata block buffers, as shown in Figure 1-9.

The tuning of the Oracle instance involves checking all of the initializationparameters for the Oracle database. As most Oracle professionals know, the Oracleinit.ora parameters are getting more complex as the Oracle database becomes moresophisticated. Chapter 9 will take a very close look at all of the Oracle init.oraparameters and provide techniques and guidelines for understanding how tochange the Oracle initialization parameters for optimal performance.

Because the Oracle instance contains the data buffer cache, we’ll also discusshow STATSPACK measures the behavior of the data buffer pools. These pools includethe DEFAULT pool, the KEEP pool, and RECYCLE pool. We will show STATSPACKtechniques that can be used to identify when the size of the data storage buffer poolsneed to be increased, and how to tune to the lowest common denominator setting forthe size of the buffer pools.

We’ll also take a look at tuning the shared pool and library cache within the OracleSGA. We will show how STATSPACK information can be collected on the behaviorof the SGA, and show techniques whereby we can adjust the relevant initializationparameters in order to maximize the behavior of objects within Oracle’s shared pool.





Object TuningVery few Oracle professionals recognize that the storage parameters for Oracle tablesand indexes can have a great impact on the performance of the database. This sectionwill explore each of the relevant storage parameters for Oracle objects and offerguidelines for setting the storage parameters according to the behavior of the object.This section will also explore object fragmentation, as shown in Figure 1-10, and offerseveral techniques to ensure that expensive database reorganizations are minimized.

FIGURE 1-9. Tuning the Oracle SGA and background processes

FIGURE 1-10. Oracle objects, freelists, and fragmentation



Chapter 10 will also go into the internals of Oracle data blocks and show theinternal mechanisms for linking and unlinking from Oracle’s freelists. By understandingthe detail in the internal operations of Oracle tables, the Oracle professional willgain insight into how to optimally set the storage parameters for maximum Oracleperformance. Of course, this chapter will also focus on the STATSPACK utility, andshow how you can derive useful information regarding the behavior of individualOracle objects within your database. We will also look into the STATSPACK tablesthat measure block wait activities on objects and see scripts that can identify thoseobjects that require adjustment to their storage parameters to improve performance.We will take a close look at the PCTFREE and PCTUSED Oracle object parameters,and understand how the settings for these parameters can dramatically improvethe performance of SQL INSERT and UPDATE tasks. We’ll also take a look at theuse of freelists within Oracle tables to understand how to identify tables that areexperiencing freelist contention, and how to set the freelists for Oracle objects inorder to maximize the throughput of high-volume transactions against these tables.

SQL TuningThe tuning of individual SQL statements is the most time-consuming of all of theprocesses in Oracle tuning. While Oracle SQL tuning is a very time-consuming job,the tuning of SQL also promises the most benefits in the overall performance of theOracle system. It is not uncommon to increase performance by an order of magnitudeby using the proper Oracle SQL tuning techniques. Chapter 11 will focus on identifyingthe high-use SQL statements within your database and will present a proven techniquefor tuning the SQL to ensure that it always runs in an optimal fashion.

This chapter will also show how to use the Oracle STATSPACK utility in order tomonitor the behavior of SQL within your library cache and periodically alert the Oracleprofessional to SQL statements that may not be optimized for maximum performance.This is done by examining the SQL source in the stats$sql_summary table.

There is also a section on managing SQL statements within the library cache.As every Oracle professional knows, SQL statements are very transient within theOracle instance, and may only reside in the library cache for a short period of time.At any given point in time, information with the library cache may change. SQLstatements that enter the library cache remain in the library cache until they age-outand are no longer available to the Oracle instance. Chapter 11 will show you thatyou can capture SQL execution information from the library cache. This valuabletechnique will allow you to interrogate the library cache at any given point in timeand prepare detailed reports showing the execution plans for all of the importantSQL statements that are in the Oracle library cache.

The STATSPACK utility monitors the library cache information and can be usedto create automated alert reports that will show whenever poorly tuned SQL statementsare being executed within the Oracle instance.





We will also go into detail regarding the various optimizer modes for Oracle SQL.We will take a close look at the relative advantages and disadvantages of the cost-basedoptimizer (CBO), and also examine the rule-based optimizer and where it can be usedto improve the throughput of Oracle SQL. We will also look at the differences betweenthe first_rows and all_rows modes within the cost-based optimizer.

When tuning individual SQL statements, we will show how to change the executionplans with the use of SQL hints. We will examine actual examples for SQL tuningand show how the execution time of SQL statements can be reduced from hoursdown to only a few minutes. We’ll also take a look at initialization parameters thataffect the performance of Oracle SQL and take a close look at the Oracle8i featureof static SQL binding with the optimizer plan stability feature. For Oracle8i, we willalso examine the query rewrite feature within SQL and see how it can be used toimprove SQL performance.

Tuning with Oracle Parallel QueryChapter 12 will focus on Oracle Parallel Query and show different methods that canbe used to invoke parallelism in cases where full table scans are being performedagainst large tables. We begin by showing how to find large-table full table scans andthen discuss the different methods that can be used for parallelizing these kinds ofqueries. We’ll also show how to set the degree of parallelism in order to maximize thethroughput and execution time of the individual query, based on the number of CPUsand the number of disks for the table’s file.

We will also discuss parallel DML and how operations such as parallel indexrebuilds can improve the speed of database maintenance activities. Chapter 12 alsoexamines how submitting concurrent requests to Oracle can parallelize many largeOracle tasks.

Tuning the Oracle Parallel Server EnvironmentChapter 13 will discuss the Oracle Parallel Server (OPS) product (known as RealApplication Clusters in Oracle9i), and describe the characteristics of applicationsystems that will benefit from using an Oracle Parallel Server environment. Wewill discuss the hardware configurations necessary for Oracle Parallel Server, andalso take a look at application partitioning techniques that can be used maximizethroughput in an Oracle Parallel Server environment. This chapter will also take alook at determining the optimal number of instances for Oracle Parallel Server, andwill focus on the Integrated Distributed Lock Manager (IDLM). We will take a closelook at the IDLM parameters, and show how STATSPACK can be extended in orderto collect information on the behavior of the IDLM in a production environment.We’ll also take a close look at pinging between instances, and understand howpinging can be minimized by partitioning application structures.







Now that we have covered the overall approach to tuning, we need to look athow STATSPACK is used to facilitate the tuning effort.

Oracle and STATSPACKWhile the main focus of this text is on practical techniques for Oracle tuning, you’llfind its STATSPACK is used as a common thread throughout the body of this text. UsingSTATSPACK as a vehicle for aiding performance tuning is a very important conceptthat will be the main focus of the chapters in this book. While you can back-portSTATSPACK to Oracle 8.0 releases by using the statsrep80.sql report, there are someknown problems with the utility. The report from STATSPACK on an Oracle releaselevel prior to 8.1.6 has inaccuracies with the data and cannot always be trusted.

We will begin in Chapter 2 with an overview of the STATSPACK utility and showhow Oracle STATSPACK is installed and configured in order to measure Oracle servermetrics. We will show the installation procedure for the STATSPACK tables, thearchitecture of all of the STATSPACK tables, and a complete listing showing youwhere to find all of the salient server metrics that you need in order to pull usefulinformation from the STATSPACK tables.

We will also take a look at the nature of STATSPACK snapshots, and show how tocreate reports that average metrics over time, as well as look at specific time intervals,spanned over long periods of time. This is an especially important technique becauseit shows the Oracle professional how to slice the STATSPACK information in order toget exactly what they are looking for.

We will take a look at sample queries that can be run against the STATSPACKtables and learn how we can get relevant metrics from STATSPACK to identify whatwas happening in our database at any given point in time.

While this text will utilize prewritten STATSPACK scripts, it’s very important forthe Oracle professional to understand the nature of STATSPACK queries and be ableto formulate their own queries based upon the specific problem that they encounterwithin the Oracle environment. There are many dozens of scripts that come as apart of this text, but the Oracle professional will always be encouraged to extendupon these reports, and use them to see additional details about their system.

Because the STATSPACK utility is limited to the domain of the Oracle database,we will show some of the ways that Oracle STATSPACK can be extended to captureinformation from the external environment. We will begin by showing how STATSPACKcan be extended to capture server metrics, and we will devote Chapter 5 to exploringhow the UNIX vmstat utility can be used to capture server information and store themin STATSPACK extension tables. We will also show how the Oracle professional caninterrogate these tables and see what’s going on inside the database server whenperformance problems occur.





We will also extend the STATSPACK tables by capturing information on disk I/O.We will devote Chapter 8 to the tuning of the disk I/O subsystem so that the Oracleprofessional can understand the nature of disk I/O, the interaction between Oracle fileplacement and disk I/O, and how STATSPACK can be extended to monitor what’sgoing on in the I/O subsystem over time.

Towards the end of this book we will also take a look at the extension ofSTATSPACK towards long-term statistical trend reporting. In Chapters 14 and 15,you’ll find dozens of useful scripts that allow you to plot important Oracle metricsover time and use the existing statistics as a predictive model for developing a planfor additional database resources. While it is not necessary to have a background instatistics to fully understand the techniques in Chapter 15, it is important the Oracleadministrator have a general knowledge of the Oracle performance metrics and howthey may change over time.

When doing Oracle trend analysis with STATSPACK, it’s important to understandthat we will be aggregating information along many dimensions. For example, wewill use Oracle scripts that will show you how to aggregate information by day ofthe week, so that you can see the relative stress on your system during specific daysof the week, as shown in Figure 1-11.

We will also show how to break down Oracle STATSPACK information by hourof the day, so the Oracle professional can see on an hourly basis when end-userprocesses are causing stress on the Oracle database, as shown in Figure 1-12.

FIGURE 1-11. A day-of-the-week average report





We will use the same techniques for the measurement of daily and hourlyinformation to extrapolate the overall performance of the database over periodsof weeks and months. By taking summarized STATSPACK information and feedingit into statistical analysis routines, we can use predictive models to perform linearregression and predict the future performance of the Oracle database based uponthe existing metrics.

We will also briefly cover the different methods for linear regression, includingsingle, double, and triple exponential smoothing techniques as well as the morecommon sum-of-the-least-squares techniques for predicting overall Oracleperformance.

These long-term trend reports are especially useful for the manager who is chargedwith predicting the amount of hardware resources required for the Oracle systems.We will show scripts that will accurately predict future disk storage requirements,future RAM memory requirements, as well as future CPU requirements—all basedon statistics gathered from the STATSPACK tables over time.

For plotting STATSPACK information, it is important that we use a tool that isavailable to almost all Oracle administrators. While a powerful statistical packagesuch as SAS or SPSS can give incredibly detailed analysis of statistics, we’ve chosenin this book to use the Microsoft Excel worksheet product. By confining our examplesto MS Excel, we can provide easy to understand methods for extracting, plotting, andpredicting the behavior of our database all using tools that are readily available onmost desktops, as shown in Figure 1-13.

FIGURE 1-12. An hour-of-the-day average activity summary





Because STATSPACK has been configured to capture virtually everything that’sgoing on in an Oracle database at any given point in time, you’ll find that there aremany hundreds of metrics that are useful when captured within the STATSPACK tables.While it is very tempting for this author to cover every single one of these metrics,it’s more important to the practicing Oracle professional that we focus only on thoseserver metrics of the most importance for the tuning of the Oracle system. Hence,we will confine our discussion to those metrics that will provide the Oracle professionalwith the information they need to very quickly make intelligent performance andtuning decisions for their system.

ConclusionThroughout this book you will be directed to various STATSPACK tables that willallow you to investigate the values that relate to the concepts we are discussing.This combination of experienced Oracle tuning techniques and the use of STATSPACKmakes this a truly unique text.

Now, let’s get started and begin with an overview of the STATSPACK utility.

FIGURE 1-13. A sample of a predictive STATSPACK trend analysisusing MS Excel



chapter 1books.mhprofessional.com/downloads/products/... · 8 oracle high-performance tuning with...

Documents