1. Introduction

2. Agenda Performance Tuning(성능 조정) size 조정 ← 문제점 ← 진단 ← 진단 방식 ← DB 이해
I/O → Disk 분산 조정Parameter 조정
Performance 목표 :
목표 : Response time 최소화 + Concurrent Throughput
Response time이란 자원 소비 시간을 말한다.
Response time
= Service tim(수행 시간) + wait time(지연 시간)
성능 향상
사용자가 체감할 수 있는 수치적 증명 수준으로 끌어 올리는 것을 말한다.
예시 : 분당 처리 건수가 500건이었는 데 100건으로 떨어졌다.
이런 경우에 진단이 필요하다.

3. Oracle Database 10g: Performance Tuning 1-3
Course Objectives
After completing this course, you should be able to do the following:
Use the Oracle database tuning methodology appropriate to the available tool
Utilize database advisors to proactively tune an Oracle database
Use the tools based on Automatic Workload Repository to tune the database
Use Statspack reports to tune the database
Diagnose and tune common database performance problems
Use Enterprise Manager performance-related pages to monitor an Oracle database
Oracle Database 10g: Performance Tuning 1-3

4. Oracle Database 10g: Performance Tuning 1-4
Agenda
Automatic Shared Memory Management 10 3
Tuning the Buffer Cache 9
Tuning the Shared Pool 8 2
Reactive Tuning 7
Using Automatic Workload Repository 6
Using Statspack 5 1
Metrics, Alerts, and Baselines 4
Statistics and Wait Events
Performance Tuning: Overview
Introduction
Topic
Lesson
Day
Oracle Database 10g: Performance Tuning 1-4

5. Oracle Database 10g: Performance Tuning 1-5
Agenda
Performance Tuning: Summary 15 4
Tuning Block Space Usage 14
Tuning PGA and Temporary Space 13
Tuning I/O 12
Checkpoint and Redo Tuning 11 3
Topic
Lesson
Day
Oracle Database 10g: Performance Tuning 1-5

6. Oracle Database 10g: Performance Tuning 1-6
Tuning Questions
Who tunes?
What to tune?
How to tune?
Oracle Database 10g: Performance Tuning 1-6

7. Oracle Database 10g: Performance Tuning 1-7
Who Tunes?
The people who are involved with tuning:
Database administrators
Application architects
Application designers
Application developers
System administrators
Who Tunes?
Everyone involved with the Oracle database software including system architects, designers, developers, database administrators, and system administrators should think about performance.
If problems develop, then the database administrator (DBA) usually makes the first attempt at resolving them. Therefore, the DBA should have an accurate overview of all the applications in the database, and their interactions with each other. DBAs often enlist the aid of developers for application tuning, or system administrators for tuning OS and I/O issues. This course is intended for the DBA responsible for ongoing tuning and monitoring of an Oracle database. However, anyone involved in the design, development, and deployment of an Oracle database can also benefit.
Oracle Database 10g: Performance Tuning 1-7

8. The focus of this course Oracle Database 10g: Performance Tuning 1-8
What to Tune Overall?
Performance tuning areas:
Application:
Poorly written SQL
Serialized resources
Poor session management
Instance tuning:
Memory
Database structure
Instance configuration
Operating system:
I/O
Swap
Parameters
The focus of this course
What to Tune Overall?
To have a well-tuned system, you must carefully design systems and applications. Common performance problems can be grouped as follows:
Application issues: Poorly written SQL, serialized resources, and poor session management
Instance Issues: Memory, I/O and Instance configuration
Operating system issues: Swap, I/O, parameter settings, and network issues
You achieve the largest return on investment of time and effort by tuning the application. Tuning the SQL statements, the access paths, and the storage structures are all important parts of application tuning.
Instance tuning and application tuning use different sets of skills and tools. Separate courses are available to address the specific skills and tools used in application tuning. Application tuning is dependent on the type of application. Data warehouse applications and online transaction processing applications use different access methods and data structures for performance. Operating system tuning is dependent on the operating system being used. There are separate courses available to address these areas: Oracle Database 10g: SQL Tuning Workshop for OLTP tuning and statement tuning, and Oracle Database 10g: Implement and Administer a Data Warehouse for data warehouse issues.
Oracle Database 10g: Performance Tuning 1-8

9. Oracle Database 10g: Performance Tuning 1-9
What to Tune Overall? (continued)
Some database issues require assistance from the system administrator. This course addresses some of the generic issues. Separate courses are available for Linux- and Windows-based systems that deal with OS-specific issues. The Linux course covers many issues that are generic to UNIX and UNIX-like operating systems.
Oracle Database 10g: Performance Tuning 1-9

10. What to Tune in the Instance
Instance tuning areas:
Memory: (20% OS / 80% oracle)
Insufficient memory
Poorly allocated memory
I/O:
Insufficient bandwidth
Poorly allocated disk space
Poor database configuration
Instance configuration:
Inappropriate instance parameters
Poor recovery and availability configuration
What to Tune in the Instance
This course focuses on instance tuning: memory, I/O, and instance configuration. This is the typical realm of the DBA. The workshop examples use well-tuned SQL statements, so you can focus on instance issues. Outside of the practice environment the problems will not be so clearly defined. Application issues can appear to be instance issues. Application tuning and instance tuning overlap. Sometimes an instance can be tuned to compensate for application problems.
Instance tuning areas can be broken down further:
Memory issues: Insufficient memory or poorly allocated memory
I/O issues: Insufficient bandwidth, poorly allocated disk space, or poor database configuration
Instance configuration: Inappropriate instance parameters, and poor recovery and availability configuration
Oracle Database 10g: Performance Tuning 1-10

11. Oracle Database 10g: Performance Tuning 1-11
How to Tune
The procedures used to tune depend on the tool:
Basic tools:
Dynamic performance views (V$)
Statistics(통계)
Metrics(측정단위=측정 기준치=변화율)
Enterprise Manager pages:성능탭
AWR or Statspack ($?/rdbms/admin/utlbstat.sql)
Automatic Database Diagnostic Monitor (ADDM)
DBA scripts
How to Tune
The methodology that you use varies with the tools that are available.
If you have Oracle Database 10g: Enterprise Edition with the optional tuning packs, Automatic Database Diagnostic Monitor (ADDM) is available, along with other Automatic Workload Repository (AWR)–based tools.
If you have Oracle Database 10g: Standard Edition, then the tool to use is Statspack.
The steps for using both tools, ADDM and Statspack, are covered in this course.
In addition, many DBAs have developed their own tools and scripts for tuning.
All tuning tools are dependent on the basic tools of the dynamic performance views, statistics, and metrics that are collected by the instance.
Oracle Database 10g: Performance Tuning 1-11

12. Traditional Performance Tuning Methodology Challenges
Data collection
Replay the workload.
Understand/correlate raw statistics.
Data analysis
Solution implementation
Prioritize solutions by impact.
Traditional Performance Tuning Methodology Challenges
There are three main phases in any performance tuning methodology:
Data collection: In this phase, you need to identify the information relevant to diagnosing performance problems and set up an infrastructure to collect that information on a regular basis. However, your biggest challenge is to be able to replay the workload that causes the problems you encounter so that you can evaluate your solution.
Data analysis: This phase is probably the most difficult because it needs an expert to understand and correlate all the relevant statistics together.
Solution implementation: In this phase, you are often faced with multiple solutions for different problems identified during the previous phase. However, you need to use your own judgment to prioritize and quantify the solutions by impact.
Oracle Database 10g: Performance Tuning 1-12

13. Performance Monitoring Solutions
Automatic
Fore- -ground
MMON
60 mn
In-memory statistics
SGA
ASH
Snapshots
Snapshots
ADDM
Alerts
DBA
Statspack
AWR
Performance Monitoring Solutions
In addition to the classical reactive tuning capabilities of previous releases, such as Statspack, SQL trace files, and performance views, Oracle Database 10g includes new methodologies to monitor your database:
Proactive monitoring with Automatic Database Diagnostic Monitor (ADDM): This component is the ultimate solution for Oracle database tuning. ADDM automatically identifies bottlenecks within the Oracle database. Additionally, working with other manageability components, ADDM makes recommendations about the options available for fixing these bottlenecks.
Reactive monitoring:
Server-generated alerts: The Oracle database server can automatically detect problematic situations. Reacting to a detected problem, the Oracle database server sends you an alert message with possible remedial action.
The Oracle database server has powerful new data sources and performance-reporting capabilities. Database Control provides an integrated performance management console that uses all relevant data sources. Using a drill-down method, you can manually identify bottlenecks with just a few mouse clicks.
ADDM results
Oracle Database 10g: Performance Tuning 1-13

14. Oracle Database 10g: Performance Tuning 1-14
Performance Monitoring Solutions (continued)
Data sources are included to capture important information about your database’s health—for example, memory statistics (for current diagnostics) as well as statistics history stored in Automatic Workload Repository (AWR).
AWR simplifies performance data collection, and it has been designed with a high degree of manageability, automation, and data collection efficiency, and after careful consideration of the data volume collected. AWR is a part of the Database Diagnostics pack along with other features such as the Automatic Database Diagnostic Monitor (ADDM).
If you use the Database Diagnostics pack, the first place to go for performance diagnostic help is ADDM. ADDM simplifies performance diagnosis by making it automatic, using the data collected by AWR. If you are licensed to use the Diagnostics Pack, you should use ADDM to perform the diagnostic work for you. For up-to-date license information specific to your release, refer to the Oracle Database Licensing Information manual. If you use the Database Diagnostics pack, you should use only AWR to capture performance data.
Notes only slide
Oracle Database 10g: Performance Tuning 1-14

15. Using Features of the Packs
Monitoring and tuning with packs
Monitoring and tuning without packs
SQL traces
Statspack
System statistics
Wait model
Time model
OS statistics
Metrics
Service statistics
Histograms
Optimizer statistics
SQL statistics
Using Features of the Packs
The management packs names and features are listed on the left part of the slide. They all require a separate license that can be purchased only with Enterprise Edition. The features in these packs are accessible through Oracle Enterprise Manager Database Control, Oracle Enterprise Manager Grid Control, and APIs provided with the Oracle database software:
Oracle Database Diagnostic Pack provides automatic performance diagnostic and advanced system-monitoring functionality. The following are part of this pack:
The DBMS_WORKLOAD_REPOSITORY package
The DBMS_ADVISOR package, if you specify ADDM as the value for the ADVISOR_NAME parameter, or if you specify any value starting with the ADDM prefix for the value of the TASK_NAME parameter
The V$ACTIVE_SESSION_HISTORY dynamic performance view
All data dictionary views beginning with the DBA_HIST_ prefix, along with their underlying tables
All data dictionary views with the DBA_ADVISOR_ prefix if queries to these views return rows with the value ADDM in the ADVISOR_NAME column or a value of ADDM* in the TASK_NAME column or the corresponding TASK_ID
Oracle Database 10g: Performance Tuning 1-15

16. Oracle Database 10g: Performance Tuning 1-16
Using Features of the Packs (continued)
The following reports found in the /rdbms/admin/ directory of the ORACLE_HOME directory are part of this pack: awrrpt.sql, awrrpti.sql, addmrtp.sql, addmrpti.sql, awrrpt.sql, awrrpti.sql, addmrpt.sql, addmrpti.sql, ashrpt.sql, ashrpti.sql, awrddrpt.sql, and awrddrpi.sql.
Oracle Tuning Pack provides expert performance management for the Oracle database environment, including SQL tuning and storage optimizations. The Oracle Diagnostic Pack is a prerequisite product to the Oracle Tuning Pack. Therefore, to use the Tuning Pack, you must also have a Diagnostic Pack. The following are part of this pack:
The DBMS_SQLTUNE package
The DBMS_ADVISOR package, when the value of the ADVISOR_NAME parameter is either SQL Tuning Advisor or SQL Access Advisor
The sqltrpt.sql report found in the /rdbms/admin/ directory of the ORACLE_HOME directory.
Oracle Configuration Management Pack automates the time-consuming and often error-prone process of software configuration, software and hardware inventory tracking, patching, cloning, and policy management.
If you cannot purchase the packs mentioned above, especially the Database Diagnostics and Database Tuning packs, you can still use the traditional approach to performance tuning and monitoring by using Statspack reports, SQL traces, and most of the base statistics as shown in the previous slide.
Notes only slide
Oracle Database 10g: Performance Tuning 1-16

17. Tuning Scenario Alternatives
Without ADDM
With ADDM
Examine system utilization.
Review ADDM recommendations.
Look at wait events.
ADDM recommends use of CURSOR_SHARING.
Observe latch contention.
See wait on shared pool and library cache latch.
Review V$SYSSTAT.
See parse time elapsed > parse time CPU and #hard parses greater than normal.
Identify SQL by reviewing V$SQL for many statements with same hash plan.
Examine objects accessed and review SQL.
Tuning Scenario Alternatives
The slide compares the tuning steps with and without the use of ADDM for a hard parse scenario.
Here are the steps involved when you do not use ADDM:
1. You receive a call from a user complaining that the system is slow.
2. You examine the server machine and see that there are plenty of resources available, so obviously the slowdown is not due to the OS problems on the machine.
3. You look at the database instance and see that many of the sessions are waiting on latch free waits.
4. Drilling down into the latches, you see that most of the latch free waits are on library cache and shared pool latches.
5. From experience and referring to a number of books on the subject, you know that these latches are often associated with hard-parsing issues. As a double check, you look at the rate at which the statistics parse time elapsed and parse time CPU are increasing. You also observe that the elapsed time is accumulating much faster than CPU time. Your suspicion is confirmed.
Identify hard parse issue by observing the SQL contains literals.
Enable cursor sharing.
Oracle Database 10g: Performance Tuning 1-17

18. Oracle Database 10g: Performance Tuning 1-18
Tuning Scenario Alternatives (continued)
6. At this stage, you have several ways to proceed, all of which try to identify skewed data distribution. One way is to look at the statistics for parse count (hard) for all sessions to see whether there is one or more sessions responsible for the majority of the hard parses. An alternative is to examine the shared pool to determine whether there are many statements with the same SQL plan, but with different SQL text. In your example, you do the latter and find that there are a small number of plans associated with many different SQL texts.
7. When you review a few of these SQL statements, you determine that the SQL statements contain literal strings in WHERE clauses and so each of the statements must be separately parsed.
8. Having seen cases like this before, you can now say that the root cause of the problem is hard parsing caused by not using bind variables, and can move on to fixing the problem.
The following are the steps involved when using ADDM for the same scenario:
i. You receive a call from a user complaining that the system is slow.
ii. You examine the latest ADDM report and the first recommendation reads:
FINDING 3: 31% impact (7798 seconds)
SQL statements were not shared due to the usage of literals. This resulted in additional hard parses which were consuming significant database time.
RECOMMENDATION 1: Application Analysis, 31% benefit (7798 seconds)
ACTION: Investigate application logic for possible use of bind variables instead of literals. Alternatively, you may set the parameter "cursor_sharing" to "force". Decrease hard parsing
RATIONALE: SQL statements with PLAN_HASH_VALUE were found to be using literals. Look in V$SQL for examples of such SQL statements.
From this information, you immediately know that over 30% of the time is being spent parsing and a recommendation as to what to do to resolve the situation is provided. Note that the finding also includes a suspect plan hash value to allow you to quickly examine a few sample statements.
Notes only slide
Oracle Database 10g: Performance Tuning 1-18

19. Oracle Database 10g: Performance Tuning 1-19
Tuning Methodology
Tuning steps:
Tune from the top down:
The design before tuning the application code
The code before tuning the instance
Tune the area with the greatest potential benefit:
Identify the longest waits.
Identify the largest service times.
Stop tuning when the goal is met.
Tuning Methodology
Oracle has developed a tuning methodology based on years of experience. The methodology presented in this course is also presented in the Oracle Database Performance Tuning Guide. This methodology is applied independent of the tools that you use. The ADDM tool follows this methodology automatically. The basic steps are the following:
Check the OS statistics and general machine health before tuning the instance to be sure that the problem is in the database instance.
Tune from the top down. Start with the design, then the application, and then the instance. As an example, try to eliminate the full table scans causing the I/O contention before tuning the tablespace layout on disk. The design should use appropriate data structures for the application and load characteristics. For example, reverse key indexes may work well in a RAC environment to reduce hot blocks due to a sequential primary key, but it may also lead to a large number of blocks being shipped across the interconnects if every instance is inserting into the same table. The application should avoid processes that require serialization though a single resource. A simple example is a single check number generator used by multiple processes. Tuning at the instance level is often limited by design and application choices.
Oracle Database 10g: Performance Tuning 1-19

20. Oracle Database 10g: Performance Tuning 1-20
Tuning Methodology (continued)
Tune the area with greatest potential benefit. The tuning methodology presented in this course is simple. Identify the biggest bottleneck and tune it. Repeat. All the various tuning tools have some way to identify the SQL statements, resource contention, or services that are taking the most time. Oracle Database 10g provides a time model and metrics to automate the process of identifying bottlenecks.
Stop tuning when you meet your goal. This step implies that you set tuning goals.
This is a general approach to tuning the database instance and may require multiple passes.
From a practical perspective, tuning during the design and development phases of a project tends to be more top down. The tuning efforts during testing and production phases are often reactive and bottom up. In all phases, tuning depends on actual test cases because theoretical tuning does not know all the variables that can be present. After a problem area is suspected, or discovered, a test case is created and the area tuned as in all the examples given in this course. Tune the area that has the greatest potential benefit. Reduce the longest waits and the largest service times.
Notes only slide
Oracle Database 10g: Performance Tuning 1-20

21. Oracle Database 10g: Performance Tuning 1-21
Summary
In this lesson, you should have learned how to:
Identify tuning tools
Utilize a tuning methodology
Oracle Database 10g: Performance Tuning 1-21