Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Standard view
Full view
of .
Look up keyword or section
Like this

Table Of Contents

0 of .
Results for:
No results containing your search query
P. 1
DBA11gvol 3 Performance Tuning

DBA11gvol 3 Performance Tuning

|Views: 384|Likes:
Published by kiran0123456789

More info:

Categories:Topics, Art & Design
Published by: kiran0123456789 on Nov 15, 2011
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Introduction to Performance Tuning Page 1 of 134www.wilshiresoft.com Wilshire Software Technologies Rev. Dt: 10-Oct-08info@wilshiresoft.com Ph: 2761-2214 / 5577-2214 Version: 6
1. Introduction to Performance Tuning
1.1. System Architecture
Limitations of Hardware ComponentsMost multiprocessor machines can get close to linear scaling with a finite number of CPUs, but after a certain pointeach additional CPU can increase performance overall, but not proportionately. There might come a time when anadditional CPU offers no increase in performance, or even degrades performance. This behavior is very closelylinked to the workload and the operating system setup.
These factors are based on Oracle Server Performance group’s experience of tuning unscalable systems.There are two main parts to a system’s architecture:
Hardware and Software Components
Configuring the Right System Architecture for Your Requirements
1.2. Hardware and Software Components
This section discusses hardware and software components.
1.2.1. Hardware Components
Today’s designers and architects are responsible for sizing and capacity planning of hardware at each tier in amultitier environment. It is the architect's responsibility to achieve a balanced design. This is analogous to a bridgedesigner who must consider all the various payload and structural requirements for the bridge. A bridge is only asstrong as its weakest component. As a result, a bridge is designed in balance, such that all components reach theirdesign limits simultaneously. The main hardware components include:
I/O Subsystem
NetworkCPU: There can be one or more CPUs, and they can vary in processing power from simple CPUs found in hand-helddevices to high-powered server CPUs. Sizing of other hardware components is usually a multiple of the CPUs on thesystem.Memory: Database and application servers require considerable amounts of memory to cache data and avoid time-consuming disk access.I/O Subsystem: The I/O subsystem can vary between the hard disk on a client PC and high performance disk arrays.Disk arrays can perform thousands of I/Os each second and provide availability through redundancy in terms ofmultiple I/O paths and hot pluggable mirrored disks.Network: All computers in a system are connected to a network; from a modem line to a high speed internal LAN.The primary concerns with network specifications are bandwidth (volume) and latency (speed).
1.2.2. Software Components
The same way computers have common hardware components, applications have common functional components.By dividing software development into functional components, it is possible to better comprehend the applicationdesign and architecture. Some components of the system are performed by existing software bought to accelerateapplication implementation, or to avoid re-development of common components.The difference between software components and hardware components is that while hardware components onlyperform one task, a piece of software can perform the roles of various software components. For example, a diskdrive only store and retrieves data, but a client program can manage the user interface and perform business logic.Most applications involve the following components:
Introduction to Performance Tuning Page 2 of 134www.wilshiresoft.com Wilshire Software Technologies Rev. Dt: 10-Oct-08info@wilshiresoft.com Ph: 2761-2214 / 5577-2214 Version: 6
Managing the User Interface
Implementing Business Logic
Managing User Requests and Resource Allocation
Managing Data and TransactionsThere are number of database performance issues. One of the most common was the lack of a simple structuredmethodology for achieving performance improvements in today’s production applications. In previous releases of theOracle Server there has been a tuning manual that describes how to tune various types of contention. This approachprovided detailed information but did not provide a simple methodology that could be understood from PerformanceEngineer to CIO. Future releases of the Oracle Server documentation will provide a method document as well asperformance reference manual to meet this objective.After many intense discussions between performance experts, it was possible to define a performance methodologyfor performance improvement. The focus of this methodology is to make dramatic performance improvements to anapplication in production. The targeted performance improvements are very often an order of magnitude improvementover the existing configuration rather than small incremental improvements ( less than 10% ) achieved by simpleconfiguration tuning. The methodology focuses on two core issues, which are described as follows:
Dramatically increasing application efficiency, which means reducing the number of system resources usedin the execution of a business transaction.
Elimination of the biggest bottleneck within the application that may cause serialization within an applicationor system resource starvation. These two may naturally be the same bottleneck.By focusing on these two objectives it is possible to remove much of the perceived mystique associated withperformance improvement on Oracle Servers. In essence, a performance problem is caused by one or more of thefollowing:
An inefficient application
An application that serializes when multiple users access the application
The database is badly implemented onto the hardware
It cannot be emphasized enough that application efficiency has more impact on overall scalability than anyother aspect of the system, yet in many cases receives the least tuning and performance.
1.3. Oracle Performance Improvement Methods
Issues such as system configuration are relatively simple when setup correctly from the beginning. This methodologythe common errors made in system setup. Future developments made to analytical tools make bottleneckdetermination simpler and more logical. In particular, the following tools have been improved to allow determination ofserialization points, resource intensive users, frequently executed and resource intensive SQL statements:
Statspack shipped with the Oracle server provides a mechanism for collecting database statistics over timeand producing a report that highlights potential database problems.
The Performance, Diagnostic and Tuning parts of OEM have been enhanced to include database healthscreens with interactive drill downs, a database and operating system statistics repository, reporting facilityand extensive user and SQL analytical tools.
These tools should not be considered a substitute for a performance engineers experience but rathercomplimentary analytical tools, which expose bottleneck determination in a more efficient manner.By providing a Performance Improvement Methodology in conjunction with these performance tools, we are providinga framework where both junior and senior performance engineers can determine the biggest bottleneck. However,the expectation is that a more senior engineer would determine the largest bottleneck faster and more accuratelythan a junior engineer. As in life, there is no replacement for experience.The Oracle Performance Improvement Method is as follows:
Get candid feedback from users. Determine the performance project’s scope and subsequent performancegoals, as well as future performance goals. This process is key for future capacity planning.
Get a full set of operating system, database, and application statistics from the application where theperformance is both good and bad. If statistics are scarce, then gather whatever information is available.
Introduction to Performance Tuning Page 3 of 134www.wilshiresoft.com Wilshire Software Technologies Rev. Dt: 10-Oct-08info@wilshiresoft.com Ph: 2761-2214 / 5577-2214 Version: 6
Issuing statistics are analogous to missing evidence at a crime scene - they make detective work harder andmore time consuming. Every piece of data has value and should not be overlooked.
Sanity check the operating system of all machines involved with user performance. By definition, whenexamining the operating system, you should look for hardware or operating system resources that are fullyutilized. List any over-used resources as symptoms for analysis later. In addition, check all hardware forerrors or diagnostic information.
List the applicable mistakes’ as symptoms for analysis later. These items are important to list because thereis likelihood that they may be responsible for the performance problems.
Build a conceptual model of what is happening on the system using the symptoms as clues to understandwhat has caused the performance problems.
Propose a series of remedy actions and the anticipated behavior to the system, and apply them in an orderthat will most benefit the application. The golden rule in performance work is that you only change one thingat a time and then measure the difference. Unfortunately, system downtime requirements might prohibitsuch a rigorous investigation method. If multiple changes are applied at the same time, then try to ensurethat they are isolated.
Validate that the changes made have had the desired effect, and see if the user's perception of performancehas improved. Otherwise, look for more symptoms, and continue refining the conceptual model until yourunderstanding of the application becomes more accurate.
Repeat the last three steps until performance goals are met or become impossible due to other constraints.
1.4. Common Oracle Performance Mistakes
Bad Connection Management: The application connects and disconnects for each database interaction. Thisis common problem with stateless middleware in application servers. This mistake has over two orders ofmagnitude impact on performance, and it is totally unscalable.
Bad Use of Cursors and the Shared Pool: Not using cursors results in repeated parses. If bind variables arenot used, then hard parsing occurs of all SQL statements. This has an order of magnitude impact inperformance, and it is totally unscalable. Use cursors with bind variables that open the cursor and re-execute it many times. Be suspicious of applications generating dynamic SQL.
Getting Database I/O Wrong: Many sites lay out their databases poorly over the available disks. Other sitesspecify the number of disks incorrectly, because they configure disks by disk space and not I/O bandwidth.
Redo Log Setup Problems: Many sites run with too few redo logs which are too small. Small redo logs causesystem checkpoints to continuously put a high load on the buffer cache and I/O system. If there are too fewredo logs, then the archive cannot keep up, and the database stalls.
Serialization of data blocks in the buffer cache due to lack of free lists, free list groups, transaction slots(INITRANS), or shortage of rollback segments: This is particularly common on INSERT-heavy applications,in applications that have raised the block size to 8K or 16K, or in applications with large numbers of activeusers and few rollback segments.
Long Full Table Scans: Long full table scans for high volume or interactive online operations could indicatepoor transaction design, missing indexes, or poor SQL optimization. Long table scans, by nature, are I/Ointensive and unscalable.
In Disk Sorting: In disk sorts for online operations could indicate poor transaction design, missing indexes, orpoor SQL optimization. In disk sorts, by nature, are I/O intensive and unscalable.
High Amounts of Recursive (SYS) SQL: Large amounts of recursive SQL executed by SYS could indicatespace management activities, such as extent allocations, taking place. This is unscalable and impacts userresponse time. Recursive SQL executed under another user ID is probably SQL and PL/SQL, and this is nota problem.
Schema Errors and Optimizer Problems: In many cases, an application uses too many resources becausethe schema owning the tables has not been successfully migrated from the development environment orfrom an older implementation. Examples of this are missing indexes or incorrect statistics. These errors canlead to sub-optimal execution plans and poor interactive user performance. When migrating applications ofknown performance, export the schema statistics to maintain plan stability using the DBMS_STATSpackage. Likewise, optimizer parameters set in the initialization parameter file can override proven optimalexecution plans. For these reasons, schema’s, schema statistics, and optimizer settings should be managedtogether as a group to ensure consistency of performance.
Use of Nonstandard Initialization Parameters: These might have been implemented based on poor advice orincorrect assumptions. In particular, parameters associated with spin count on latches and undocumentedoptimizer features can cause a great deal of problems that can require considerable investigation. In today’s

Activity (3)

You've already reviewed this. Edit your review.
1 hundred reads
Nizam Shaik liked this
Mushtaq Ahmed liked this

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->