Analysing Oracle AWR Reports

Author Owner: Document Reference: Version: Issue Date: Authoriser

Shailendra S. Hirlekar BCM-STAR, Infosys 0.1 09-Mar-2011

Analysing Oracle AWR reports

Document Control
Amendment Record
Version 0.1 Date 09-Mar-2011 Status Draft Description of Revision Shailendra Hirlekar

Abbreviations
Term AWR FTS PGA SGA AMM Definition Automatic Workload Repository Full Table Scan Program Global Area System Global Area Automatic Memory Management

0.2

Page 2 of 18

Analysing Oracle AWR reports

Table of Contents

0.2

Page 3 of 18

Analysing Oracle AWR reports

1 Introduction 1.1 Purpose of Document

AWR (Automatic Workload Repository) Reports are very handy during performance tuning of the database. These reports provide clear picture of database side activities. Various useful data is nicely documented in different sections in readable format. It becomes necessity to understand these reports for teams involved in activities like database tuning, performance/ load testing or analysing any performance issue. Purpose of the document is to enable the reader to understand basic AWR terminology and to use these details for understanding the database performance issues.

1.2 Scope
This document describes how to utilize AWR reports to tune, Physical database instance Identify SQLs which are performing poorly

1.3 Intended audience

This document is intended for: Performance/ Load testing team Oracle DBAs Development team

0.2

Page 4 of 18

Analysing Oracle AWR reports

2 AWR Walk through

AWR reports are divided into various sections. Each section provides specific information about database health. We will go through each of the important sections and will try to explore information captured in these sections.

2.1 Instance information

DB Name XXXX DB Id Instance Inst num Release 1 10.2.0.4.0 RAC YES Host XXXXXX 11882829 XXXXX

Provides information about the database, 1. Name of the database 2. Database ID 3. Instance Name and Instance Number 4. Oracle Database Server release version 5. Whether database is part of RAC? 6. Machine name hosting the database instance

Snap Id Begin Snap: End Snap: Elapsed: DB Time: 605 606

Snap Time 31-Jan-11 17:00:07 31-Jan-11 18:00:04 59.96 (mins) 820.16 (mins)

Sessions 433 438

Cursors/Session 7.4 7.5

Before we go through this table, we will see, 2.1.1 How AWR reports are generated?

Starting from Oracle 10g onwards, at every 60 mins database server takes snapshot of a database. Snapshot gathers database health related information at that point of time. This information is stored in Oracle data dictionary and servives database restarts. Each snapshot is identified by a snapshot ID. In order to generate AWR reports, 2 snapshot IDs are needed. Latest of these snapshots is compared with old snapshot and based on the comparison an AWR report gets generated. Above table provides information about, 1. Begin Snapshot ID and End Snapshot ID along with date and time details for the snapshot 2. The Sessions column indicates total no. of database sessions active when the snapshot was taken. 3. Elasped Time column indicates the duration in mins between 2 snapshots. In this example, the duration is approx. 60 mins 4. DB Time columns represents, total time spent by foreground processes. It includes CPU Time, IO Time and Wait time and excludes Idle wait time and time taken by background processes. (DB time) / (Elapsed time) gives total no. of database active sessions during that period. In case of above scenario total no. of active sessions are, 820.16 (DB Time) / 59.96 (Elapsed Time), which is 13.67 sessions.

2.2 Cache Sizes

Begin Buffer Cache: 740M End 724M Std Block Size: 8K

0.2

Page 5 of 18

Analysing Oracle AWR reports

Shared Pool Size: 264M 280M Log Buffer: 6,148K

The section gives information about size details for memory componets 1. 2. 3. 4. Buffer Cache Shared Pool Standard Block Size Log Buffer

From Oracle 10g onwards, database server does Automatic Memory Management (AMM) for PGA and SGA components. Based on load, database server keeps on allocating or deallocating memory assigned to different components of SGA and PGA. Due to this reason, we can observe different sizes for Buffer Cache and Shared Pool, at the beginning or end of AWR snapshot period.

2.3 Load Profile

Per Second Redo size: Logical reads: Block changes: Physical reads: Physical writes: User calls: Parses: Hard parses: Sorts: Logons: Executes: Transactions: 1,638,781.89 309,768.35 9,284.70 1,830.10 237.61 531.06 481.48 47.43 596.32 0.03 2,546.83 52.54 Per Transaction 31,189.97 5,895.64 176.71 34.83 4.52 10.11 9.16 0.90 11.35 0.00 48.47

This section provides information Per Second and Per Transaction basis. For example it shows, 1. 2. 3. 4. How many Hard Parse are happening How much Redo is generated How many Physical Reads are happening etc How many Sorts are happening

This information is proportionate to the amount of load experienced by the database server during that period. 2.3.1 How load profile information is helpful during load testing?

Ans: Load testing for application release is done to assess the release performance. Load test is first done on baseline version and then performed on the release version. It is recommended to generate AWR reports for baseline as well as for the release load test. In order to assess performance of release test against baseline test, we can compare the load profile section of AWR for both the tests. This comparison will give slight idea about the release performance. If there are significant differences in the count of baseline and release load profile figures, then that could give some pointers for investigation in case the release load test is bad in terms of performance. 2.3.2 Is it ok to keep the snapshot frequency to default i.e. every 60 minutes?

To analyse the performance issues in detail, it is recommended to generate AWR reports with interval less than 60 min. May be one can generate AWR reports at every 10 minutes only during the load test interval, and later change the frequency to default one. 0.2 Page 6 of 18

Analysing Oracle AWR reports

2.4 Instance Efficiency Percentages (Target 100%)

Buffer Nowait %: Buffer Hit %: Library Hit %: Execute to Parse %: Parse CPU to Parse Elapsd %: 99.29 Redo NoWait %: 99.41 In-memory Sort %: 78.19 Soft Parse %: 81.10 Latch Hit %: 9.09 % Non-Parse CPU: 100.00 100.00 90.15 99.44 98.03

The section provides information about hit ratios for different memory components. These ratios, tells how often a particular data is found in a respecitive memory structure. Details about hit ratios are as mentioned delow, Buffer Hit: Shows % of times particular block was found in buffer cache, instead of reading it from disk. Buffer Nowait: Indicates % of times data buffers were accessed directly without any wait time. Library Hit%: Shows % of times SQL and PL/SQL found in shared pool. In-Memory Sort %: Shows % of times Sorting operations happened in memory than in the disk (temporary tablespace). Soft parse %: Shows % of times the SQL in shared pool is used. Latch Hit %: Shows % of time latches are acquired without having to wait. As per Oracle AWR report the target should be 100% for these ratios. But in reality this is not possible always. Hence the ratio above 80% is always healthy.

2.5 Shared Pool Statistics:

Begin Memory Usage %: % SQL with executions>1: % Memory for SQL w/exec>1: 91.36 85.32 95.71 End 90.18 78.53 97.93

% SQL with executions>1: Shows % of SQLs executed more than 1 time. The % should be very near to value 100. % memory for SQL w/exec>1: From the memory space allocated to cursors, shows which % has been used by cursors more than 1. The ratio above 80% is always healthy.

2.6 Top 5 Timed Events:

Event cursor: pin S wait on X CPU time db file sequential read read by other session row cache lock 6,301,396 7,022,258 1,881,861 Waits 963,939 Time(s) 10,958 10,932 9,923 5,819 3,899 2 1 2 Avg Wait(ms) 11 % Total Call Time 22.2 20.2 User I/O 11.8 User I/O 7.9 Concurrency Wait Class 22.3 Concurrency

This section shows TOP 5 wait events the processes were waiting on during the snapshot time period. These events are helpful during analysis of any database related performance bottlenecks. The Wait Class, column helps in classifying whether the issue is related to application or infrastructure.

0.2

Page 7 of 18

Analysing Oracle AWR reports Waits, column provides information about no. of wait happens. Time(s), column provides information about total CPU time in seconds spent on the wait.

Important wait events and their causes are explained in detail below, 2.6.1 db file scattered read:

This event indicates wait due to full table scans or index fast full scans. To avoid this event, identify all the tables on which FTS is happening and create proper indexes so that oracle will do Index scans instead of FTS. The index scan will help in reducing no. of IO operations. To get an idea about tables on which FTS is happening please refer to Segment Statistics -> Segments By Physical Read section of AWR report. This section lists down both Tables and Indexes on which Physical Reads are happening. Please note that physical reads doesnt necessarily means FTS but a possibility of FTS. 2.6.2 db file sequential read:

The event indicates that index scan is happening while reading data from table. High no. of such event may be a cause of unselective indexes i.e. oracle optimizer is not selecting proper indexes from set of available indexes. This will result in extra IO activity and will contribute to delay in SQL execution. Generally high no. is possible for properly tuned application having high transaction activity. 2.6.3 buffer buzy wait:

Indicates that particular block is being used by more than one processes at the same. When first process is reading the block the other processes goes in a wait as the block is in unshared more. Typical scenario for this event to occur is, when we have batch process which is continuously polling database by executing particular SQL repeatedly and there are more than one parallel instances running for the process. All the instances of the process will try to access same memory blocks as the SQL they are executing is the same. This is one of the situation in which we experience this event. 2.6.4 enq: TX - row lock contention:

Oracle maintence data consistency with the help of locking mechanism. When a particular row is being modified by the process, either through Update/ Delete or Insert operation, oracle tries to acquire lock on that row. Only when the process has acquired lock the process can modify the row otherwise the process waits for the lock. This wait situation triggers this event. The lock is released whenever a COMMIT is issued by the process which has acquired lock for the row. Once the lock is released, processes waiting on this event can acquire lock on the row and perform DML operation.

2.7 Time Model Statistics:

Statistic Name sql execute elapsed time DB CPU parse time elapsed hard parse elapsed time hard parse (sharing criteria) elapsed time hard parse (bind mismatch) elapsed time PL/SQL compilation elapsed time PL/SQL execution elapsed time sequence load elapsed time repeated bind elapsed time connection management call elapsed time Time (s) 45,168.56 10,932.03 8,626.43 7,616.90 929.82 929.20 731.51 440.62 409.34 26.35 6.02 % of DB Time 91.79 22.22 17.53 15.48 1.89 1.89 1.49 0.90 0.83 0.05 0.01

0.2

Page 8 of 18

Analysing Oracle AWR reports

DB time background elapsed time background cpu time 49,209.52 1,774.14 448.11

Important statistics here is the DB Time. The statistic represents total time spent in database calls. It is calculated by aggregating the CPU time and wait time of all sessions not waiting on idle event (non-idle user sessions). Since this timing is cumulative time for all non-idle sessions, it is possible that the time will exceed the actual wall clock time. Objective of tuning oracle database is to reduce the amount of time users spend in performing some action on the database. This time represents time taken by foreground sessions and not background sessions. In above example, DB Time is 49,209.52 seconds. 91% of the time is being spent on SQL execution elapsed time i.e for SQL execution. DB CPU represents time spent on CPU resource by foreground user processes. This time doesnt include waiting time for CPU. DB CPU is contributing to 22% of total DB time. Important thing to note here is, the actual wall clock time is around 3600 seconds (difference between 2 snapshots) but the DB CPU shown here is 10,932 seconds. If the server machine (on which database server is running) has more than 1 CPUs, it is possible to have DB CPU greater than actual wall clock time. In this example the database server is hosted on machine with 8 CPUs. Hence a 1 second is divided into 8 parts. Hence DB CPU 10,932 seconds means, 10,932 (DB CPU) / 8 (CPU) = 1366 wall clock seconds. The Parse time elapsed and Hard parse elapsed time has taken around 17% and 15% of the total DB time. Parse time elapsed represents time spent for Syntax and Semantic checks. Whereas Hard parse include time represents time spent for Syntax and Semantic checks PLUS time spent for optimizing the SQL and generating optimizer plan.

2.8 Wait Class:

Wait Class Concurrency User I/O Commit Cluster System I/O Other Configuration Application Network Waits 3,371,424 13,397,731 235,762 1,307,191 208,454 2,018,321 26,428 1,643 2,770,033 %Time -outs 28.51 0.00 0.00 0.00 0.00 14.36 17.80 0.00 0.00 Total Wait Time (s) 16,439 15,930 2,988 1,323 911 475 309 34 21 Avg wait (ms) 5 1 13 1 4 0 12 21 0 Waits /txn 17.83 70.87 1.25 6.91 1.10 10.68 0.14 0.01 14.65

The events are sorted in descending order of Total Wait Time (s) column. There are over 800 distinct wait events. Oracle has grouped these wait events in 12 wait classes. These wait classes are further divided in 2 categories, Administrative Wait Class and Application Wait Class. These wait classes gives overall information about whether the waits happening for Application or for System events. In the example above first 2 rows show that total wait time is higher for Concurrency and User I/O wait classes. Though we wont have much control on reducing concurrency, but we could aim at reducing the User IO. High User IO means, From the pool of available indexes proper indexes are not being used FTS is happening on big tables with millions of rows

This could give pointers for further tuning. 0.2 Page 9 of 18

Analysing Oracle AWR reports

2.9 Wait Events:

Event cursor: pin S wait on X db file sequential read read by other session row cache lock log file sync gc buffer busy log file parallel write library cache load lock enq: TX - index contention latch: cache buffers chains kksfbc child completion gc current grant 2-way library cache lock enq: SQ - contention gc cr grant 2-way gc current block 2-way enq: HW - contention db file parallel write db file scattered read latch: shared pool log file sequential read latch: row cache objects latch: library cache direct path write gc cr multi block request buffer busy waits latch: session allocation direct path read enq: TX - row lock contention ksxr poll remote instances reliable message Waits 963,939 6,301,396 7,022,258 1,881,861 235,762 835,453 145,027 17,095 24,548 172,466 5,527 175,219 78,169 17,467 141,816 103,694 4,142 44,214 31,617 81,395 3,652 40,058 19,479 18,866 49,879 25,287 26,429 21,708 914 1,570,668 286 %Time -outs 99.70 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 98.72 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 13.71 5.59 Total Wait Time (s) 10,958 9,923 5,819 3,899 2,988 752 716 420 378 292 276 257 195 194 148 115 112 92 89 87 80 76 65 53 50 42 39 39 34 23 22 Avg wait (ms) 11 2 1 2 13 1 5 25 15 2 50 1 2 11 1 1 27 2 3 1 22 2 3 3 1 2 1 2 37 0 78 Waits /txn 5.10 33.33 37.15 9.95 1.25 4.42 0.77 0.09 0.13 0.91 0.03 0.93 0.41 0.09 0.75 0.55 0.02 0.23 0.17 0.43 0.02 0.21 0.10 0.10 0.26 0.13 0.14 0.11 0.00 8.31 0.00

The wait events are sorted on Total Wait Time (s) column in descending order. The idle events are listed down in the end. First 10 to 15 events should be looked into because rest of the events are idle events and can be ignore. These events are related to foreground processes.

2.10 Background Wait Events:

Event log file parallel write db file parallel write log file sequential read events in waitclass Other row cache lock control file sequential read latch: row cache objects control file parallel write gc current block 2-way library cache lock Waits 145,047 44,226 3,659 1,651,179 10,726 9,724 9,547 1,497 3,159 1,464 %Time -outs 0.00 0.00 0.00 17.00 0.00 0.00 0.00 0.00 0.00 0.00 Total Wait Time (s) 716 92 81 71 35 14 13 6 5 4 Avg wait (ms) 5 2 22 0 3 1 1 4 2 2 Waits /txn 0.77 0.23 0.02 8.73 0.06 0.05 0.05 0.01 0.02 0.01

0.2

Page 10 of 18

Analysing Oracle AWR reports

latch: shared pool Log archive I/O db file sequential read cursor: pin S wait on X library cache pin os thread startup latch: cache buffers chains gc current grant 2-way gc cr grant 2-way 3,523 3,642 862 137 47 8 70 120 323 0.00 0.00 0.00 100.00 0.00 0.00 0.00 0.00 0.00 4 3 3 2 1 0 0 0 0 1 1 4 12 12 62 7 3 1 0.02 0.02 0.00 0.00 0.00 0.00 0.00 0.00 0.00

The wait events are sorted on Total Wait Time (s) column in descending order. The idle events are listed down in the end. First 10 to 15 events should be looked into because rest of the events are idle events and can be ignore. These events are related to background processes.

2.11 SQL Statistics:

This is a very important section. This section lists down TOP SQL details based on, Elapsed Time CPU Time No. of Gets No. of Reads No. of Executions etc.

2.11.1 SQL ordered by Elapsed Time:

Elapsed Time CPU Time Elap per Exec % Total DB Executions (s) (s) (s) Time 7,678 1,202 905 88 59 55 54 43 37 35 503 97 89 11 11 2 16 5 10 2 20,391 1 0.00 35.01 2 57,158 27.37 0.00 1,004 1 70 41,246 7.65 1202.04 12.93 0.00

SQL Id

SQL Module

SQL Text

15.6093pczysczy6ut

XXXXXXXX select MOD(NVL(translate(B.XXX...

2.447pusny3989p7b XXXXXXXX declare XXX_XXXX XXX_XXX... 1.84ftz3ja1zr82s5 0.186qz82dptj0qr7 0.122k3bu9k1p7kyz XXXXXXXX select ID , TO_CHAR(XXXX,... select l.col#, l.intcol#, l.... select /*+ INDEX(ol$ ol$signat...

0.119pwx7hnjcgwyh XXXXXXXX select xxxx.xxxxxxx... 0.11cqgv56fmuj63x 0.099g485acn2n30m 0.0839m4sx9k63ba2 0.0777zqh2uy696by XXXXXXX select owner#, name, namespace... select col#, intcol#, reftyp, ... select /*+ index(idl_ub2$ i_id... SELECT DISTINCT XX.XXXXXX...

The section provides TOP SQLs sorted in descending order by, Elapsed Time(s). Elapse per Exec (s): Elapse time in seconds for per execution of the SQL. Executions: Total no. of executions for the SQL during the two snapshot period. Elapsed Time: This is calculated by multiplying Elapse per Exec (s) by Executions. % Total DB Time: % of DB time utilized by the SQL.

0.2

Page 11 of 18

Analysing Oracle AWR reports SQL Module: Provides module detail which is executing the SQL. Process name at the OS level is displayed as SQL Module name. If the module name starts with any of the names given below, then dont consider these SQLs for tuning purpose as these SQLs are oracle internal SQLs, DBMS sqlplusw TOAD rman SQL Enterprise Manager ORACLE MMON_SLAVE emagent etc

This section is very important in terms of tuning perspective as it provides information about SQLs which need tuning. During load testing one should compare this section for Release load test and with baseline load test. This comparison will give difference about which SQLs performed badly during baseline and release load test. Looking at the column, Elapse per Exec (s), one can understand which SQLs need tuning. Normally SQLs taking time above 1 second are candidate for tuning. For other sections like, SQL ordered by Gets, SQL ordered by CPU Time etc, the SQLs appearing under SQL ordered by Elapsed Time are listed most of the time. Hence this section is worth investigating. Below is the brief description about each section, SQL ordered by CPU Time: SQLs are listed based on CPU time taken and are ordered by, CPU Time (s) column. SQL ordered by Gets: SQLs are listed based on Buffer Reads (Buffer Gets) for the SQL and are ordered by, Buffer Gets, column. SQL ordered by Reads: SQLs are listed based on Physical Reads (Disk Reads) for the SQL and are ordered by, Physical Reads, column. SQL ordered by Executions: SQLs are listed based on total no. of executions for the SQL and are ordered by, Executions, column.

For each of these sections, to get the complete SQL Text details, click on the SQL ID listed under SQL ID column.

2.12 Instance Activity Stats - Thread Activity

Statistic log switches (derived) Total 2 per Hour 2.00

This section provides information about how many Redo Log Switches are happening. The Total column provides information for log switches during the snapshot period and per hour column provides information per Hour basis. 2 log switches per hour is optimal value as per oracle standards.

3 Advisory Statistics 3.1 Buffer Pool Advisory

P Size for Est (M) Size Factor Buffers for Estimate Est Phys Read Factor Estimated Physical Reads

0.2

Page 12 of 18

Analysing Oracle AWR reports

D D D D D D D D D D D D D D D D D D D D D 72 144 216 288 360 432 504 576 648 720 728 792 864 936 1,008 1,080 1,152 1,224 1,296 1,368 1,440 0.10 0.20 0.30 0.40 0.49 0.59 0.69 0.79 0.89 0.99 1.00 1.09 1.19 1.29 1.38 1.48 1.58 1.68 1.78 1.88 1.98 8,622 17,244 25,866 34,488 43,110 51,732 60,354 68,976 77,598 86,220 87,178 94,842 103,464 112,086 120,708 129,330 137,952 146,574 155,196 163,818 172,440 4.35 2.03 1.54 1.42 1.33 1.25 1.17 1.11 1.06 1.01 1.00 0.95 0.89 0.84 0.80 0.77 0.73 0.70 0.66 0.59 0.51 2,937,669,401 1,371,604,952 1,038,346,123 959,213,827 899,213,101 844,100,667 793,922,143 752,192,096 716,041,579 680,211,989 676,024,586 642,521,274 603,505,502 570,790,229 543,401,299 518,133,473 491,055,525 470,256,432 447,139,441 396,093,338 347,627,804

The section provides estimates on, how the increase or descrease of buffer cache size will casue decrease or increase in physical reads. This information is just an estimated data and not an actual data. Starting point here is Size Factor = 1.0. This gives current memory allocation for Buffer Cache. In this example, 728 MB is being allocated to buffer cache. With this setting the estimated amount of Physical Reads are 676,024,586. In case we increase the memory allocation for buffer cache to say 1440 MB (Size Factor = 1.98) then estimated physical reads will be 347,627,804. This means by allocating additional 712 MB for Buffer Cache, total estimated physical reads will come down by 328,396,782. On the other hand, by reducing Buffer Cache to say 216 MB (Size Factor = 0.30) estimated physical reads increase to 1,038,346,123. The statistics acts as an input to DBA in order to tune the Buffer Cache memory.

3.2 PGA Memory Advisory

PGA Target Est (MB) 384 768 1,536 2,304 3,072 3,686 4,301 4,915 5,530 6,144 9,216 12,288 18,432 24,576 Size Factr 0.13 0.25 0.50 0.75 1.00 1.20 1.40 1.60 1.80 2.00 3.00 4.00 6.00 8.00 W/A MB Processed 812,978.60 812,978.60 812,978.60 812,978.60 812,978.60 812,978.60 812,978.60 812,978.60 812,978.60 812,978.60 812,978.60 812,978.60 812,978.60 812,978.60 Estd Extra W/A MB Read/ Written to Disk 178,424.72 172,475.22 30,048.28 25,473.80 25,473.80 10,796.70 10,796.70 10,796.70 10,796.70 10,796.70 10,796.70 10,796.70 10,796.70 10,796.70 Estd PGA Cache Hit % 82.00 82.00 96.00 97.00 97.00 99.00 99.00 99.00 99.00 99.00 99.00 99.00 99.00 99.00 Estd PGA Overalloc Count 3,834 3,763 0 0 0 0 0 0 0 0 0 0 0 0

0.2

Page 13 of 18

Analysing Oracle AWR reports Similar to Buffer Pool Advisory, the statistic provides information on how the increase or decrease in PGA memory will cause increase or decrease in Estd PGA Cahce Hit %. Starting point here is Size Factor = 1.0. This gives current memory allocation for PGA. In this example 3072 MB is being allocated to PGA. With this allocation the Estd PGA Cahce Hit % is 97, which is good. Hence even if we increase PGA to 3686 MB we will get 2% increase in Estd PGA Cahce Hit %. Hence it wont be advisable to increase PGA further.

3.3 Shared Pool Advisory

Shared Pool Size(M) 252 280 308 336 364 392 420 448 476 504 532 560 SP Size Factr 0.90 1.00 1.10 1.20 1.30 1.40 1.50 1.60 1.70 1.80 1.90 2.00 Est LC Size (M) 28 55 82 109 136 163 190 217 244 271 298 325 Est LC Mem Obj 6,586 7,434 8,379 9,352 10,362 11,293 12,185 13,193 14,377 15,293 16,196 17,328 Est LC Time Saved (s) 6,921,060 7,477,642 8,020,189 8,461,984 8,790,828 9,040,418 9,242,662 9,414,811 9,567,814 9,703,054 9,814,500 9,907,118 Est LC Time Saved Factr 0.93 1.00 1.07 1.13 1.18 1.21 1.24 1.26 1.28 1.30 1.31 1.32 Est LC Load Time (s) 614,333 57,751 1 1 1 1 1 1 1 1 1 1 Est LC Load Time Factr 10.64 1.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Est LC Mem Obj Hits 58,238,179 58,323,146 58,403,382 58,459,714 58,496,766 58,523,514 58,544,538 58,561,861 58,576,296 58,588,125 58,597,966 58,606,158

Similar to Buffer Pool Advisory and PGA, the statistic provides information on how the increase or decrease in Shared pool memory will cause increase or decrease in Estd LC Load Time (s). Starting point here is SP Size Factor = 1.0. This gives current memory allocation for shared pool. In this example 280 MB is being allocated to shared pool. With this allocation the Estd LC Load Time (s) is 57,751. If we increase the shared pool size to 308 then Estd LC Load Time (s) will come down to value 1. Hence shared pool should be set to 308 MB.

3.4 SGA Target Advisory

SGA Target Size (M) 512 768 1,024 1,280 1,536 1,792 2,048 SGA Size Factor 0.50 0.75 1.00 1.25 1.50 1.75 2.00 Est DB Time (s) 3,062,724 2,689,285 2,417,105 2,246,714 2,084,044 1,885,603 1,885,608 Est Physical Reads 1,038,371,906 844,082,787 676,023,376 570,766,536 470,241,860 347,611,220 347,611,220

The statistic provides information on how the increase or decrease in SGA memory will cause decrease or increase in Estd Physical Reads. Starting point here is SGA Size Factor = 1.0. This gives current memory allocation for SGA. In this example 1024 MB is being allocated to SGA. With this allocation the Estd Physical Reads is 844,082,787. If we increase the SGA size by 1024 MB i.e. to 2048 MB then Estd Physical Reads will come down by 328,412,156. Since there is 50% reduction in Estd Physical Reads, the SGA should be increased to 2048 MB.

3.5 Undo Segment Summary

Undo Num Undo Number of Max Qry Max Tx Min/Max TR STO/ uS/uR/uU/

0.2

Page 14 of 18

Analysing Oracle AWR reports

TS# 16 Blocks (K) 176.25 Transactions 233,218 Len (s) 135 Concurcy (mins) OOS 0/0 eS/eR/eU 0/0/0/0/0/0

45 15/15.25

The statistic proivides information about UNDO segments. Min/MAX TR (mins) Represents Minimum and Maximum Tuned Retention Minutes for Undo data. This data will help to set the UNDO_RETENTION database parameter. In this example this parameter can be set to 15.25 minutes i.e. 915 seconds. Max Qry Len(s) Represents Maximum query length in seconds. In this example the max query length is 135 seconds. STO/ OOS Represents count for Sanpshot Too Old and Out Of Space errors, occurred during the snapshot period. In this example, we can see 0 errors occurred during this period.

4 Segment Statistics 4.1 Segments by Logical Reads

Owner XXX_OWNER XXX_OWNER XXX_OWNER XXX_OWNER XXX_OWNER Tablespace Name XXX_DATA XXX_DATA XXX_DATA XXX_DATA Object Name XXXX_XXXX _IX_03 XXXX_XXXX XXX_XXX_XXX XXX_XX_XXX_XXXXX Subobject Name Obj. Type INDEX TABLE TABLE INDEX TABLE Logical Reads 817,720,480 68,558,256 58,728,272 17,506,640 6,542,848 %Total 73.37 6.15 5.27 1.57 0.59

XXX_INDEX XXX_XXXX_IX_05

The statistic displays segment details based on logical reads happened. Data displayed is sorted on Logical Reads column in descending order. It provides information about segments for which more logical reads are happening. Most of these SQLs can be found under section SQL Statistics -> SQL ordered by Gets.

4.2 Segments by Physical Reads

Owner XXX_OWNER XXX_OWNER XXX_OWNER XXX_OWNER XXX_OWNER Tablespace Name XXX_DATA XXX_INDEX XXX_INDEX XXX_DATA XXX_INDEX Object Name XXX_XXX_XXXX XXX_XXXXXX_IX_03 XXXX_XXXX_IX_03 XXXX_XXXX XXX_XXXX_IX_01 Subobject Name Obj. Type TABLE INDEX INDEX TABLE INDEX Physical Reads 2,112,621 1,649,590 776,458 381,302 259,326 %Total 32.09 25.05 11.79 5.79 3.94

The statistic displays segment details based on physical reads happened. Data displayed is sorted on Physical Reads column in descending order. It provides information about segments for which more physical reads are happening. Queries using these segments should be analysed to check whether any FTS is happening on these segments. In case FTS is happening then proper indexes should be created to eliminate FTS. Most of these SQLs can be found under section SQL Statistics -> SQL ordered by Reads.

4.3 Segments by Row Lock Waits

Owner XXX_OWNER XXX_OWNER XXX_OWNER XXX_OWNER Tablespace Name XXX_DATA Object Name XXX_XXX_IX_04 Subobject Name Obj. Type INDEX INDEX INDEX TABLE Row Waits 6,907 3,918 3,118 1,750 Lock % of Capture 20.18 11.45 9.11 5.11

XXX _INDEX XXX_XXXX_IX_03 XXX _INDEX XXX_XXX_PK XXX _DATA XXX_XXX_XXXX

0.2

Page 15 of 18

Analysing Oracle AWR reports

XXX_OWNER XXX _INDEX XXX_XXXX_IX_02 INDEX 1,178 3.44

The statistic displays segment details based on total Row lock waits which happened during snapshot period. Data displayed is sorted on Row Lock Waits column in descending order. It provides information about segments for which more database locking is happening. DML statements using these segments should be analysed further to check the possibility of reducing concurrency due to row locking.

4.4 Segments by ITL Waits

Owner XXX_OWNER XXX_OWNER XXX_OWNER XXX_OWNER XXX_OWNER Tablespace Name Object Name Subobject Name Obj. Type INDEX INDEX INDEX INDEX INDEX ITL Waits 23 15 10 10 8 % of Capture 27.06 17.65 11.76 11.76 9.41 XXX_INDEX XXX_XXXXX_IX_01 XXX_INDEX XXX_XXX_IX_08 XXX_INDEX XXX_XX_XXX_IX_01 XXX_INDEX XXX_XXX_IX_05 XXX_INDEX XXX_XXX_IX_10

Whenver a transaction modifies segment block, it first add transaction id in the Internal Transaction List table of the block. Size of this table is a block level configurable parameter. Based on the value of this parameter those many ITL slots are created in each block. ITL wait happens in case total trasactions trying to update same block at the same time are greater than the ITL parameter value. Total waits happening in the example are very less, 23 is the Max one. Hence it is not recommended to increase the ITL parameter value.

4.5 Segments by Buffer Busy Waits

Owner XXX_OWNER XXX_OWNER XXX_OWNER XXX_OWNER XXX_OWNER Tablespace Name XXX_INDEX XXX_INDEX XXX_INDEX XXX_INDEX XXX_INDEX Object Name XXX_XXXXX_PK XXX_XXXXX_IX_03 XXX_XXXXX_IX_03 XXX_XXXXX_PK XXX_XXXXX_PK Subobject Name Obj. Type INDEX INDEX INDEX INDEX INDEX Buffer Busy Waits 4,577 1,824 1,715 827 696 % of Capture 26.69 10.64 10.00 4.82 4.06

Buffer busy waits happen when more than one transaction tries to access same block at the same time. In this scenario, the first transaction which acquires lock on the block will able to proceed further whereas other transaction waits for the first transaction to finish. If there are more than one instances of a process continuously polling database by executing same SQL (to check if there are any records available for processing), same block is read concurrently by all the instances of a process and this result in Buffer Busy wait event.

4.6 Library Cache Activity

Namespace BODY CLUSTER INDEX SQL AREA TABLE/PROCEDURE TRIGGER Get Requests 17 14,335 113 846,225 314,825 4 Pct Miss 35.29 1.10 68.14 3.54 0.64 0.00 Pin Requests 1,260,957 41,182 340 14,397,753 3,419,828 200,436 Pct Miss 0.38 0.49 37.94 13.37 0.69 Reloads 1,875 43 35 256,865 1,085 Invali- dations 0 0 0 3,028,117 0 0

26.05 3,143,888

0.2

Page 16 of 18

Analysing Oracle AWR reports Pct Misses should be very low. In the example Pct Misses are above 10 for some of the library cache components. This indicates that the shared pool is not sufficiently sized. In case AMM (Automatic Memory Management) is used then the DBA can increase the SGA component. In case AMM is not used then increase the SHARED_POOL memory component.

0.2

Page 17 of 18

Analysing Oracle AWR reports

5 References
Oracle 10g documentations Documents availanle on Oracle Support Site (metalink.oracle.com)

About Author: Shailendra S. Hirlekar is currently working with Infosys Technologies Ltd. as a Senior Technology Architect. He is expertise in Oracle Database Administration. He is having 12+ years of IT experience.

0.2

Page 18 of 18