Scribd
Upload
42 views5 pages

Steps To Analyzing The Key Sections of An AWR Report

Uploaded by

Jaya singh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
42 views5 pages

Steps To Analyzing The Key Sections of An AWR Report

Uploaded by

Jaya singh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

Analyzing an AWR (Automatic Workload Repository) report is essential for

understanding the performance of an Oracle database. AWR reports provide a


detailed view of various database metrics collected over a specific period, helping
DBAs identify performance bottlenecks and optimize database performance.

Key Sections of an AWR Report

1. Report Summary
2. Cache Sizes
3. Load Profile
4. Instance Efficiency Percentages
5. Top Timed Events
6. Wait Events
7. SQL Statistics
8. Instance Activity Stats
9. Time Model Statistics
10. Advisory Reports
11. Segment Statistics
12. Operating System Statistics

1. Report Summary

What It Shows:
This section provides high-level information about the database instance, including:

• DB Name: Database name.


• DB ID: Database ID.
• Instance Name: Instance name.
• Host Name: Hostname of the server.
• Start and End Snapshot Times: The start and end times of the snapshots used
for the report.
• Elapsed Time: Total time covered by the report.
• DB Time: The amount of time the database spent performing user-level activity.

How to Use It:


Use this section to understand the general context and timeframe of the AWR report. The
DB Time is particularly important as it indicates the overall workload on the database.
High DB Time relative to the elapsed time can indicate performance issues.

2. Cache Sizes

What It Shows:
Shows the sizes of the different caches (buffer cache, shared pool, etc.) before and after
the snapshot period.
How to Use It:
Use this section to ensure that the cache sizes are appropriate. Look for significant
changes in cache sizes, which could indicate automatic memory management
adjustments.

3. Load Profile

What It Shows:
Provides an overview of the database workload, including:

• Logical Reads: Number of reads from the buffer cache.


• Physical Reads: Number of reads from the disk.
• Redo Size: Amount of redo generated.
• User Calls: Number of user calls to the database.
• Parses: Number of SQL parses.
• Hard Parses: Number of hard parses.

How to Use It:


Compare logical reads to physical reads to assess the effectiveness of the buffer cache. A
high ratio of logical to physical reads suggests good cache performance. High redo size
may indicate heavy DML (insert, update, delete) activity. High parse and hard parse
counts can indicate inefficiencies in SQL execution, possibly due to poor query
optimization or lack of query reuse.

4. Instance Efficiency Percentages

What It Shows:
Shows various efficiency percentages related to the instance’s performance, such as:

• Buffer Cache Hit Ratio: Indicates the percentage of logical reads found in the
buffer cache.
• Library Cache Hit Ratio: Indicates the percentage of times SQL statements are
found in the shared pool.
• Soft Parse Ratio: Indicates the percentage of SQL parses that are soft parses (i.e.,
they use already compiled code).

How to Use It:


Aim for a Buffer Cache Hit Ratio above 90%. A low hit ratio suggests that the buffer
cache size might need to be increased. A high Library Cache Hit Ratio and Soft Parse
Ratio suggest that SQL statements are efficiently using the shared pool.

5. Top Timed Events

What It Shows:
Lists the top events by wait time, providing a quick overview of where the database is
spending the most time waiting.
How to Use It:
Focus on events with the highest Total Wait Time and Wait %. Common events
include:

• DB File Sequential Read: Indicates single block reads, often caused by index
lookups or full table scans.
• DB File Scattered Read: Indicates multiblock reads, often caused by full table
scans.
• Log File Sync: Indicates time spent waiting for redo to be written to disk, which
can be a sign of high commit rates.

Address the top events to reduce wait times and improve overall performance.

6. Wait Events

What It Shows:
Provides a detailed breakdown of all wait events, including their count, time waited, and
average wait time.

How to Use It:


Look for wait events with high counts and long average wait times. These events can
indicate performance bottlenecks. Investigate the underlying causes and adjust database
settings, queries, or application logic as necessary.

7. SQL Statistics

What It Shows:
Lists SQL statements that have consumed the most resources, categorized by:

• SQL ordered by Elapsed Time: SQL statements that took the most time to
execute.
• SQL ordered by CPU Time: SQL statements that consumed the most CPU
resources.
• SQL ordered by Gets: SQL statements that performed the most logical reads.
• SQL ordered by Reads: SQL statements that performed the most physical reads.

How to Use It:


Identify poorly performing SQL statements that consume significant resources. Review
their execution plans and consider optimizing them by adding indexes, rewriting queries,
or gathering fresh statistics.

8. Instance Activity Stats

What It Shows:
Provides statistics about various activities in the database, such as:
• Logical Reads: Number of block reads from the buffer cache.
• Physical Reads: Number of block reads from the disk.
• Redo Writes: Number of redo writes.

How to Use It:


Look for unusual activity levels that might indicate issues, such as high redo generation,
which can suggest inefficient DML operations or high log buffer waits.

9. Time Model Statistics

What It Shows:
Breaks down where the database spends its time during user calls, including:

• DB CPU: Time spent on CPU.


• DB Time: Total time spent processing user calls.
• SQL Execution Elapsed Time: Time spent executing SQL.

How to Use It:


High DB CPU indicates that the database is CPU-bound. Investigate the causes of high
CPU usage, such as inefficient SQL or insufficient CPU resources.

10. Advisory Reports

What It Shows:
Includes various advisory sections that provide tuning recommendations based on the
workload:

• Buffer Cache Advisory: Shows the impact of different buffer cache sizes on
physical reads.
• PGA Target Advisory: Shows the impact of different PGA sizes on cache hit
ratios and over-allocations.
• Shared Pool Advisory: Shows the impact of different shared pool sizes on parse
times and library cache hit ratios.

How to Use It:


Use these advisories to determine if increasing or decreasing specific memory allocations
could improve performance. For example, if the Buffer Cache Advisory suggests that
increasing the cache size would significantly reduce physical reads, consider adjusting
the cache size.

11. Segment Statistics

What It Shows:
Provides statistics on the segments that have the highest activity, including:

• Logical Reads: Number of logical reads from a segment.


• Physical Reads: Number of physical reads from a segment.
• Buffer Busy Waits: Number of waits for a segment due to buffer contention.

How to Use It:


Identify the segments with high activity or contention. Consider adding indexes,
partitioning, or optimizing access paths to reduce contention and improve performance.

12. Operating System Statistics

What It Shows:
Provides statistics about the operating system performance, including CPU usage, load
average, and memory usage.

How to Use It:


Use this section to identify potential resource constraints at the operating system level.
High CPU usage or memory swapping can indicate that the server is under-provisioned
for the current workload.

Summary

By thoroughly analyzing each section of the AWR report, you can gain a deep
understanding of your Oracle database's performance characteristics and identify areas
that need optimization. Regularly reviewing AWR reports and addressing any
performance issues they reveal can help maintain optimal database performance and
prevent bottlenecks.

You might also like