ABSTRACT

This document is a practical and in-depth guide to

Oracle Database performance tuning. It covers essential
tuning strategies across SQL optimization, I/O
management, memory configuration, and Oracle’s
diagnostic tools like AWR, ADDM, and ASH. Designed to
support both proactive and reactive tuning efforts, it
includes real-world insights from production
Oracle Database 19c environments such as banking and pharmaceutical
systems. Whether you're solving critical slowdowns or

Performance Tuning - planning for future growth, this guide equips you with
the knowledge to build and maintain fast, stable, and
scalable Oracle databases.
Complete Guide
BRIJESH MEHRA
Oracle Database 19c Performance Tuning -
Complete Guide
INTRODUCTION TO ORACLE DATABASE PERFORMANCE TUNING

Oracle Database is a leading relational database management system renowned for its robustness, scalability, and ability
to handle complex workloads. Performance tuning is the process of optimizing the database to ensure it meets
application demands with minimal response times and efficient resource utilization. This guide provides a
comprehensive exploration of Oracle Database performance tuning, covering methodologies, tools, practical examples,
and advanced techniques to help database administrators and developers enhance database efficiency. Performance
tuning addresses bottlenecks at multiple levels, including SQL queries, instance configuration, memory management,
disk input/output operations, application design, and system resources. The goal is to reduce query response times,
minimize contention, and ensure scalability under varying workloads. By leveraging Oracle’s architecture and built-in
tools, administrators can proactively monitor and optimize performance..

Oracle Database Architecture Overview

To effectively tune an Oracle Database for optimal performance, a comprehensive understanding of its underlying
architecture is essential. Oracle Database is a complex system composed of several critical components, broadly
categorized into memory structures, background processes, and physical storage elements. Each of these plays a pivotal
role in the database's overall functionality, responsiveness, and reliability.

Memory Structures:
Oracle utilizes two primary memory structures—the System Global Area (SGA) and the Program Global Area (PGA). The
SGA is a shared memory region allocated during instance startup and is accessible by all server and background
processes. It stores crucial data such as the database buffer cache (which holds copies of data blocks), the shared pool
(which caches SQL execution plans and dictionary data), the redo log buffer (used to store redo entries before they are
written to disk), and other components like the Java pool and large pool. Effective tuning of the SGA can significantly
reduce disk I/O and improve query performance.

On the other hand, the PGA is allocated to each server process individually and contains data that is private to that
process. It includes session-specific information such as sort area, session variables, and other runtime control
structures. Unlike the SGA, the PGA is not shared between processes. Tuning the PGA is essential for operations
involving sorting, hashing, and bitmap creation, especially in OLAP workloads.
Background Processes:
Several background processes support the internal operation of the Oracle instance. Among the most critical are:

• DBWn (Database Writer): Responsible for writing modified blocks from the buffer cache to the datafiles on disk.

• LGWR (Log Writer): Writes redo log entries from the redo log buffer to the online redo log files, ensuring
transaction durability.

• SMON (System Monitor): Performs crash recovery when the database is started after a failure and handles tasks
like temporary segment cleanup.

• PMON (Process Monitor): Cleans up after failed user processes by releasing resources and rolling back
uncommitted transactions.

• CKPT (Checkpoint Process): Updates the control files and datafile headers to record that a checkpoint has
occurred, which helps reduce recovery time.

Additional processes such as ARCn (Archiver), RECO (Recoverer), and MMON (Manageability Monitor) may also be active
depending on the database configuration.

Physical Storage:
At the physical layer, Oracle stores data in a variety of file types, each with specific roles:

• Datafiles contain the actual user and system data.

• Redo log files store all changes made to the data, providing the ability to recover transactions in the event of
failure.

• Control files maintain the structure of the database, including the locations of datafiles and redo logs, as well as
other critical metadata.

Together, these components form the core of the Oracle Database architecture. A deep understanding of how they
interact allows a DBA to fine-tune memory allocation, optimize process efficiency, and ensure that the storage layout
supports the performance and reliability needs of the applications it serves.
Performance Tuning Methodology

To tune an Oracle Database effectively, understanding its architecture is essential. The database consists of the instance,
which includes memory structures like the System Global Area and Program Global Area, and background processes
such as the Database Writer, Log Writer, and Checkpoint process. The database itself comprises physical files, including
datafiles, control files, and redo logs. The System Global Area stores cached data blocks, shared SQL areas, and redo
buffers, while the Program Global Area manages memory for sorting, hashing, and session-specific operations.
Background processes handle tasks like writing data to disk, logging transactions, and maintaining database consistency.
A performance baseline, capturing metrics like transaction volumes, response times, CPU usage, and input/output
statistics, is critical for tuning. For example, using the Automatic Workload Repository, administrators can collect
baseline data during peak periods, such as 9:00 AM to 11:00 AM, to compare against future performance issues.
Common bottlenecks include poorly tuned SQL, insufficient memory allocation, disk contention, and latch contention. A
systematic tuning approach involves setting performance goals, measuring current metrics, and iteratively applying
optimizations. For instance, to create a baseline snapshot, use:

```sql

BEGIN

DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT;

END;

```

This snapshot captures performance metrics for later analysis.

SQL Query Optimization Techniques

Optimizing SQL queries is one of the most impactful ways to improve overall database performance. Poorly written or
unoptimized queries can cause excessive CPU usage, memory consumption, and I/O operations, leading to significant
slowdowns--especially in high-volume transaction environments. Query tuning aims to reduce the number of database
touches, minimize resource consumption, and shorten query response times. Effective optimization involves a
combination of analysis, rewriting, indexing, and configuration adjustments. Below are detailed techniques and
strategies used in SQL query tuning within Oracle Database systems.
1. Identifying Costly Queries

The first step in optimization is identifying which queries are consuming the most resources. Tools like Oracle Enterprise
Manager (OEM), Automatic Workload Repository (AWR), and SQL Trace/TKPROF can be used to profile workload and
generate performance reports. These tools help pinpoint expensive queries based on execution time, I/O, buffer gets,
and CPU time. A direct method is querying the dynamic performance view V$SQL, which provides real-time metrics on
SQL statements:

SELECT SQL_ID, EXECUTIONS, ELAPSED_TIME, DISK_READS FROM V$SQL ORDER BY ELAPSED_TIME DESC;

This allows you to quickly find long-running queries and investigate further.

2. Using Bind Variables to Reduce Hard Parsing

One of the common performance pitfalls in Oracle databases is excessive hard parsing due to the use of literal values in
SQL statements. For instance:

-- INEFFICIENT
SELECT * FROM EMPLOYEES WHERE EMP_ID = 123;

This causes Oracle to generate a new execution plan each time a different literal value is used. Instead, using bind
variables ensures reuse of existing execution plans:

-- OPTIMIZED
SELECT * FROM EMPLOYEES WHERE EMP_ID = :EMP_ID;

Benefits include reduced CPU usage, less contention on shared memory structures, and improved scalability.

3. Leveraging Indexes Effectively

Indexes are essential for reducing full table scans and accelerating data retrieval. A well-placed index—such as a B-tree
index on a column frequently used in WHERE conditions, JOINs, or ORDER BY clauses—can drastically improve
performance. However, over-indexing or having poorly chosen indexes can lead to performance degradation during
insert/update operations.

Types of indexes to consider:

• B-tree Indexes: Best for high-cardinality columns (e.g., customer_id).

• Bitmap Indexes: Suitable for low-cardinality columns (e.g., gender, status).

• Function-based Indexes: Useful when queries involve functions (e.g., UPPER(name)).

Regularly monitor index usage using DBA_HIST_SQLSTAT and DBA_HIST_SQL_PLAN to ensure they’re being used
efficiently.
4. Avoiding SELECT *** and Reducing Data Transfer

Fetching unnecessary columns increases I/O, network load, and memory usage. Instead of:

SELECT * FROM ORDERS WHERE STATUS = 'OPEN';

Use:

SELECT ORDER_ID, CUSTOMER_ID, ORDER_DATE FROM ORDERS WHERE STATUS = 'OPEN';

Always select only the columns needed by the application logic.

5. Query Rewriting and Refactoring

Complex or nested queries may perform poorly. Refactoring them into simpler and more efficient forms is often
beneficial. Some examples:

• Use Joins Instead of Correlated Subqueries:

Correlated subqueries execute once for each row, which is inefficient for large datasets.

-- INEFFICIENT
SELECT E.NAME, E.DEPARTMENT_ID FROM EMPLOYEES E WHERE EXISTS (SELECT 1 FROM DEPARTMENTS D WHERE D.DEPARTMENT_ID
= E.DEPARTMENT_ID AND D.LOCATION_ID = 1700);

-- OPTIMIZED
SELECT E.NAME, E.DEPARTMENT_ID FROM EMPLOYEES E JOIN DEPARTMENTS D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID

WHERE D.LOCATION_ID = 1700;

 • Use WITH Clauses (Common Table Expressions):
These help simplify repeated subqueries and improve readability:

WITH RECENT_ORDERS AS (SELECT * FROM ORDERS WHERE ORDER_DATE > SYSDATE - 30) SELECT CUSTOMER_ID, COUNT(*) FROM
RECENT_ORDERS GROUP BY CUSTOMER_ID;

6. Analyzing Execution Plans

Before and after any tuning, it's critical to inspect the execution plan using EXPLAIN PLAN FOR or
DBMS_XPLAN.DISPLAY_CURSOR:

EXPLAIN PLAN FOR

SELECT * FROM EMPLOYEES WHERE DEPARTMENT_ID = 10;

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

Look for operations such as Full Table Scan, Nested Loop, or Hash Join and determine if they're optimal given the data
volume and access pattern.

7. Using Statistics and Optimizer Hints

Oracle's Cost-Based Optimizer (CBO) relies heavily on up-to-date statistics to generate efficient execution plans. Use
DBMS_STATS to gather statistics regularly:

EXEC DBMS_STATS.GATHER_TABLE_STATS('HR', 'EMPLOYEES');

In certain cases, hints like /*+ INDEX(emp emp_idx1) */ or /*+ FIRST_ROWS */ can guide the optimizer, though they
should be used sparingly and only when justified by testing.

8. Consider Query Caching and Materialized Views

In modern database environments, especially those involving complex reporting and analytical workloads, performance
can often be constrained by repeated execution of the same expensive queries. These queries, when run frequently and
against data that does not change very often, place unnecessary load on the system. To alleviate this, Oracle offers
advanced mechanisms such as query result caching and materialized views, which serve as powerful tools to enhance
efficiency and responsiveness.
Query caching is a technique that allows the database to store the result of a previously executed query in memory.
When the same query is issued again—without any changes to the underlying data—the stored result can be retrieved
directly, eliminating the need for reprocessing. This drastically reduces CPU consumption and disk I/O, as the engine
skips parsing, optimization, and execution phases. It also reduces concurrency issues by lowering contention on
frequently accessed tables. Query caching is particularly useful in environments where the same query is executed
hundreds or thousands of times per hour, such as in dashboards, reporting tools, and mobile or web applications that
display static summary data.

Materialized views serve a broader purpose. Unlike a standard view, which is a virtual representation and always
reflects the latest state of the data, a materialized view physically stores the output of a query. These are especially
helpful when the query involves complex joins, aggregations, or subqueries. By storing the output on disk, the database
can deliver the results almost instantaneously, without recalculating from the base tables each time. The materialized
view can be refreshed on demand or scheduled at intervals, depending on how fresh the data needs to be. This
approach strikes a balance between performance and data accuracy. In environments where perfect real-time data is
not critical, materialized views allow systems to scale and perform optimally even under heavy loads.

Using these features effectively requires thoughtful consideration. For example, administrators must assess how often
the data changes, how costly the original query is, and whether the performance gains justify the memory or storage
overhead. In some cases, combining both strategies—caching for quick reads and materialized views for heavy
summarizations—provides a layered optimization approach. When implemented appropriately, these techniques not
only reduce latency but also free up resources for other database operations.

Conclusion
Conclusion (for Easy Understanding)

SQL query optimization is far more comprehensive than just rewriting individual SQL queries. It represents a system-
wide strategy aimed at ensuring that a database system not only runs faster but also uses resources—such as memory,
CPU, and disk I/O—more efficiently. The ultimate goal is to deliver high performance, scalability, and responsiveness to
users and applications, regardless of the size or complexity of the underlying data.

Rather than being a single task, SQL optimization involves a combination of processes, tools, and design choices that
work together to reduce the time it takes for the database to process and return results. It looks at the big picture—how
data is accessed, how it's stored, how often it's queried, and how the database engine decides the best way to handle
each request. The benefits of optimization go beyond speed; they also contribute to better hardware utilization,
reduced operational costs, and improved user experience.

One of the foundational principles in optimization is avoiding repetitive and unnecessary work. In many systems, the
same queries are run repeatedly with little or no change. Reprocessing these queries each time can be wasteful. This is
where features like query result caching and materialized views provide huge advantages. These mechanisms allow
Oracle to store the outcome of frequently executed or resource-intensive queries, so that when they are called again,
the results are retrieved directly from memory or disk—without redoing the expensive calculations or data scanning.
This is similar to solving a tough math problem once and writing down the answer. The next time someone asks, you can
just read the answer instead of solving it again. In database terms, this means faster responses, lower CPU
consumption, and improved system throughput, all without needing to change how your application code is written.

However, true performance optimization isn't achieved through shortcuts alone. It’s a collaborative and continuous
process that requires the active involvement of both developers and database administrators (DBAs). Developers need
to write clean, efficient queries and understand how their applications interact with the database. DBAs, on the other
hand, must ensure that the database is well-configured, properly indexed, and closely monitored for performance
issues.

Some of the core tasks in this joint effort include:

• Designing queries that fetch only what is needed, avoiding unnecessary columns or tables.

• Creating and maintaining indexes on the right columns to speed up data access.

• Reviewing execution plans to understand how Oracle processes each query and identify potential bottlenecks.

• Keeping database statistics up-to-date, so the query optimizer can make smart decisions.

• Monitoring workloads regularly to identify slow-running queries and performance spikes.

In large-scale systems or production environments, this kind of proactive tuning can make the difference between a
slow, frustrating experience and a responsive, reliable application. Performance problems often grow over time if not
addressed early—especially as data grows or the number of users increases.

Here’s your content reorganized into 10 clear and separate points, each focused on one specific aspect of SQL query
optimization, without mixing concepts:

Key Areas of SQL Query Optimization

1. Write Clean and Efficient Queries

Structure queries to be simple and precise. Avoid selecting unnecessary columns or using complex joins when
they aren’t needed. Always use WHERE clauses to filter data early and reduce the workload on the database
engine.

2. Use Indexes Strategically

Indexes help Oracle quickly locate rows without scanning entire tables. Apply them to columns that are
frequently used in WHERE clauses, joins, or sorting operations. Avoid over-indexing, as too many indexes can
slow down insert and update operations.

3. Analyze Execution Plans

Every SQL query generates an execution plan that shows how Oracle retrieves data. Use tools like EXPLAIN PLAN
or SQL Monitoring to review these paths and identify inefficient operations, such as full table scans or
unnecessary nested loops.

4. Keep Statistics Up to Date

Oracle’s optimizer depends on accurate statistics about data distribution, table sizes, and index usage. Outdated
or missing statistics can cause poor execution plans. Regularly gather statistics on tables and indexes to guide
the optimizer effectively.
 5. Monitor System Performance Continuously
Use tools such as Oracle Enterprise Manager, AWR (Automatic Workload Repository), and ASH (Active Session
History) reports to monitor query performance over time. This helps detect slowdowns, peak loads, and long-
running queries that need attention.

6. Understand Workload Patterns

Identify which queries are run most frequently and which are the most resource-intensive. Focus optimization
efforts where they will have the greatest impact—on critical transactions or slow-running reports.

7. Use Query Caching When Appropriate

For frequently repeated queries that return the same results, enabling result caching can reduce response time.
This helps avoid repeated execution of costly queries on static or rarely changing data.

8. Leverage Materialized Views for Heavy Aggregations

When queries involve complex joins or large aggregations that don’t change frequently, materialized views can
store the results and serve them faster. This improves performance without requiring query rewrites.

9. Optimize Data Access Patterns

Make sure that queries retrieve only the necessary data. Avoid using SELECT * unless all columns are truly
needed. Fetching fewer rows and columns reduces memory use and network traffic.

10. Design Application Architecture with Performance in Mind

Separate OLTP (transactional) and OLAP (reporting/analytical) workloads when possible. Running heavy reports
on the same database as critical transactions can slow down both. Use read replicas, reporting databases, or
data warehouses for analytics.

These practices, when applied consistently, help build fast, efficient, and scalable Oracle-based systems that can grow
with business needs In summary, SQL query optimization is a continuous process. You don’t just do it once—you keep
doing it as the system grows, more users come in, and data increases. The goal is to make sure the database remains
fast, stable, and able to handle demand without wasting system resources. When all parts of the optimization puzzle
come together—query design, indexing, caching, materialized views, and regular monitoring—the result is a database
system that performs well, scales easily, and keeps both users and stakeholders satisfied.This approach doesn't just help
performance; it also reduces costs, improves reliability, and prepares the system to support more users or larger
workloads in the future. For any DBA or developer—even those just starting out—understanding and applying these
concepts step by step will lead to much better database systems in the long run.
Memory Tuning: SGA and PGA
Sure! Here’s a version roughly five times broader and more detailed than your original text about Memory Tuning: SGA
and PGA in Oracle 19c:

Memory Tuning in Oracle 19c: Detailed Overview of SGA and PGA Management

Oracle Database 19c provides robust mechanisms for dynamic memory management that allow the database to adjust
memory allocation automatically based on the workload demands. The two primary memory areas managed in Oracle
are the System Global Area (SGA) and the Program Global Area (PGA). Effective tuning of these memory structures is
crucial for achieving optimal database performance and efficient resource utilization.

1. System Global Area (SGA)

The SGA is a shared memory region that contains data and control information for the Oracle instance. It is shared by all
server and background processes. The SGA includes multiple components, such as the shared pool, buffer cache, redo
log buffer, large pool, Java pool, and others.

Oracle 19c supports dynamic memory tuning of the SGA via parameters like SGA_TARGET and SGA_MAX_SIZE:

• SGA_TARGET defines the total size of all SGA components combined. Oracle automatically distributes this
memory among its components based on workload.

• SGA_MAX_SIZE is the upper limit on the total SGA size and must be set equal to or larger than SGA_TARGET. It
provides a ceiling for dynamic resizing.

Key Components of the SGA to Tune

• Shared Pool: The shared pool caches SQL execution plans, dictionary information, and other control structures.
Proper sizing is vital to reduce hard parses, which occur when SQL statements cannot be reused and must be
fully parsed again, leading to higher CPU consumption and slower query execution.

• Buffer Cache: This is the memory area where Oracle caches data blocks read from disk. A well-sized buffer cache
minimizes physical I/O by keeping frequently accessed data in memory, significantly improving query response
time. The buffer cache can be divided into multiple subcaches, such as the default buffer cache, keep cache, and
recycle cache, each serving different purposes.

• Redo Log Buffer: This buffer stores redo entries (change vectors) before they are written to the redo log files.
Proper tuning helps reduce disk I/O during transaction processing.

• Large Pool and Java Pool: These specialized pools support large memory allocations for operations like backup
and recovery, parallel query execution, and Java code execution within the database.

Oracle 19c’s automatic management dynamically adjusts the size of these pools within the limits set by SGA_TARGET,
but DBAs often manually adjust individual components when specific workloads demand fine-tuned control.
2. Program Global Area (PGA)

The PGA is a private memory area used by individual server processes to store session-specific data such as sort areas,
hash join areas, and session variables. Unlike the SGA, the PGA is not shared and is allocated separately for each user
session or process.

Key parameters controlling PGA memory:

• PGA_AGGREGATE_TARGET: This parameter specifies the target total amount of PGA memory available for all
server processes combined. Oracle tries to keep the total PGA memory usage near this target.

• PGA_AGGREGATE_LIMIT: Sets an absolute limit on PGA memory usage for all server processes to avoid
excessive memory consumption that might impact the operating system.

The PGA significantly impacts query performance, especially for operations that require sorting, hashing, bitmap
merging, and other memory-intensive activities. If the PGA is under-allocated, Oracle will perform these operations on
disk (using temporary segments), which can drastically slow down query performance.

Oracle 19c supports Automatic PGA Memory Management, where the database dynamically adjusts the memory
granted to each session based on workload and the overall PGA target.

3. Automatic Memory Management (AMM)

Oracle 19c also provides an Automatic Memory Management feature, which simplifies memory tuning by allowing
Oracle to manage both SGA and PGA dynamically through the MEMORY_TARGET and MEMORY_MAX_TARGET
parameters.

• MEMORY_TARGET specifies the total amount of memory Oracle can allocate for both SGA and PGA combined.

• MEMORY_MAX_TARGET is the upper limit for this allocation.

When AMM is enabled, Oracle continuously monitors workload and system resource usage and automatically
reallocates memory between SGA and PGA components as needed. This reduces the need for manual tuning and helps
maintain consistent performance under fluctuating workloads.

However, while AMM is powerful and convenient, it may not provide the best performance in all environments,
particularly in high-demand or highly specialized workloads. In such cases, manual tuning of SGA_TARGET,
PGA_AGGREGATE_TARGET, and individual subcomponents remains essential to fine-tune the system and achieve the
best balance between resource usage and performance.

4. Practical Memory Tuning Strategies

• Avoiding excessive hard parses: Monitor the shared pool usage and configure its size to minimize hard parses.
Using SQL plan baselines and cursor sharing techniques also helps reduce parsing overhead.

• Sizing buffer cache appropriately: Analyze database buffer cache hit ratios and physical I/O metrics to
determine if the buffer cache is sized properly. Increasing buffer cache reduces disk I/O but comes at the cost of
using more memory.
 • Adjusting PGA for complex queries: Monitor query execution plans and PGA memory statistics. Queries
involving large sorts or hash joins may require more PGA memory for optimal performance.

• Monitoring and adjusting dynamically: Use Oracle’s dynamic performance views (e.g.,
V$SGA_DYNAMIC_COMPONENTS, V$PGA_TARGET_ADVICE, and V$MEMORY_DYNAMIC_COMPONENTS) to
understand how memory is allocated and used. This insight helps inform tuning decisions.

• Consider workload patterns: OLTP workloads might benefit from larger shared pools and buffer caches, while
OLAP workloads might require more PGA memory for sorting and hashing operations.

SQL Tuning and the Optimizer

SQL Tuning and the Oracle Cost-Based Optimizer: 20 Key Points Explained

SQL tuning is essential to make your database queries run faster and use fewer resources. At the heart of SQL tuning in
Oracle is the Cost-Based Optimizer (CBO), which decides the best way to run your SQL queries. This guide breaks down
the key concepts and techniques so you can understand and improve SQL performance step-by-step.

1. What is the Cost-Based Optimizer (CBO)?

The CBO is Oracle’s decision-maker for SQL execution. It evaluates multiple possible ways to run a query and estimates
the "cost" in terms of CPU, I/O, and memory. The optimizer picks the plan with the lowest estimated cost, which usually
means faster execution.

2. Why Statistics Matter

The CBO relies heavily on statistics about tables and indexes—like the number of rows, data distribution, and index
health. Without accurate, up-to-date statistics, the optimizer might guess wrong and choose slow plans.

3. Keeping Statistics Updated

You should regularly collect statistics using Oracle’s DBMS_STATS package, especially after big data changes like loads or
deletes. Fresh statistics help the optimizer make better decisions.

4. What is SQL Tuning?

SQL tuning means changing your SQL or the database environment to make queries faster. This can include rewriting
SQL, creating indexes, or adjusting optimizer settings.
5. Using the SQL Tuning Advisor

Oracle’s SQL Tuning Advisor is an automated tool that analyzes slow SQL and suggests improvements—like new indexes,
rewritten SQL, or refreshed stats. It’s a great starting point for troubleshooting.

6. SQL Plan Baselines for Stability

SQL Plan Baselines store “good” execution plans. When Oracle parses a query, it compares possible plans with these
baselines and prefers proven fast plans. This keeps SQL performance stable over time, even after upgrades or stats
changes.

7. Bind Variables Reduce Parsing

Bind variables act as placeholders in SQL. They let Oracle reuse execution plans for similar queries with different values,
reducing parsing overhead and saving CPU.

8. Why Avoid Literal Values in Queries

If you write queries with literal values (like WHERE id=123), Oracle has to parse each variant separately. Using bind
variables avoids this and improves shared pool usage.

9. Indexes Speed Up Access

Indexes let Oracle quickly find rows without scanning the whole table. Proper indexing on columns used in WHERE, JOIN,
or ORDER BY clauses is crucial for fast queries.

10. Composite Indexes Help Multi-Column Filters

When filtering on several columns, a composite index (one index on multiple columns) often works better than several
single-column indexes. The column order in the index matters and should match query predicates.

11. Function-Based Indexes for Expressions

If your queries filter on expressions like UPPER(name), normal indexes won’t help. Function-based indexes store the
computed value, allowing fast access even on transformed columns.
12. Avoid Over-Indexing

Too many indexes slow down inserts, updates, and deletes because Oracle must maintain them. Only create indexes
that your queries will actually use.

13. How to Read Execution Plans

Execution plans show the steps Oracle takes to run your SQL, including scans, joins, and sorts. Tools like EXPLAIN PLAN
or DBMS_XPLAN.DISPLAY help you see if Oracle is using indexes or doing costly full scans.

14. SQL Profiles Improve Optimizer Estimates

SQL Profiles give the optimizer extra info about data distribution and cardinality, helping it pick better plans when
standard stats aren’t enough.

15. When to Use Optimizer Hints

Hints are commands embedded in SQL to force the optimizer to use a specific method, like USE_NL for nested loops. Use
hints only after careful testing, as they override the optimizer’s judgment.

16. Avoid SELECT * for Better Performance

Selecting all columns wastes resources, especially if you only need a few. Limiting columns reduces data transfer and
memory usage.

17. Monitor SQL Performance Regularly

Use Oracle tools like AWR and ASH to track slow queries and identify changes in execution plans or resource usage. This
proactive monitoring helps catch problems early.

18. Understand Wait Events to Diagnose Bottlenecks

Wait events like db file sequential read indicate what resources SQL is waiting for, helping you find if your queries are
I/O-bound or CPU-bound.
19. Adaptive Cursor Sharing Handles Different Bind Values

Oracle can create multiple execution plans for the same SQL depending on bind variable values, improving performance
for variable workloads.

20. Parallel Execution Speeds Large Queries

For big data scans or reporting, Oracle can split work across CPU cores using parallel execution, reducing elapsed time
but requiring careful resource management.

Summary

SQL tuning revolves around helping the CBO make the best decisions. By keeping statistics fresh, using bind variables,
maintaining proper indexes, analyzing execution plans, and leveraging Oracle’s tuning tools, you can greatly improve
query performance and system responsiveness.

I/O Tuning and Storage Optimization &

Concurrency and Lock Management

I/O Tuning and Storage Optimization in Oracle: A Deep Dive

Efficient Input/Output (I/O) operations and effective storage management form the backbone of optimal Oracle
database performance. The speed and reliability of data reads and writes significantly influence how quickly queries
complete and how smoothly the entire system operates. When I/O throughput is insufficient or storage is poorly
configured, these factors become serious bottlenecks that degrade query response times and overall user experience.
Delays caused by slow disk operations cannot be fully compensated for by faster processors or increased memory alone.

In addition to storage and I/O concerns, Oracle’s concurrency and lock management mechanisms are essential for
maintaining data integrity during simultaneous multi-user access. However, if these locking processes are not carefully
monitored and tuned, they can lead to contention, blocking, and performance degradation. Balancing efficient I/O
handling with effective concurrency control is therefore vital to achieving consistent and scalable database performance.
This comprehensive guide explores practical strategies and best practices to optimize both I/O throughput and
concurrency management in Oracle environments, helping you ensure high performance and reliability.
Understanding I/O Tuning and Storage Optimization

1. Why I/O Performance Matters

Database I/O involves reading and writing data to disk, which is often the slowest part of query execution. Even
powerful CPUs or large memory caches can’t compensate for slow or overloaded storage. Thus, tuning I/O throughput
directly impacts query speed and system scalability.

2. Using ASM (Automatic Storage Management)

ASM is Oracle’s integrated volume manager and file system. It simplifies storage management and evenly distributes I/O
across all disks in a disk group. This balancing reduces hotspots and improves throughput by parallelizing reads and
writes.

• ASM automatically stripes data across multiple disks.

• It manages redundancy for fault tolerance.

• It allows online rebalancing when disks are added or removed.

3. Separating Different File Types on Storage

Physical separation of files improves I/O efficiency by reducing contention:

• Redo logs (LGWR writes sequentially and synchronously) should be on fast disks separate from datafiles.

• Datafiles hold actual table and index data and benefit from spreading across multiple disks or ASM disk groups.

• Temporary tablespaces used for sorting and joins can generate heavy I/O; placing them on separate fast storage
avoids interference.

4. Leveraging Direct Path Reads and Writes

For large table scans, Oracle can bypass the buffer cache and perform direct path I/O:

• Direct Path Reads read large chunks of data directly into the PGA, reducing buffer cache usage and CPU
overhead.

• Direct Path Writes write large temporary or sort segments directly to disk.

Properly configuring queries and tablespaces to allow direct path I/O reduces overhead and speeds up large queries.

5. Reducing I/O Contention via DBWR and LGWR Tuning

Oracle background processes like DB Writer (DBWR) and Log Writer (LGWR) handle writing dirty buffers and redo log
buffers to disk:

• Tune DBWR to flush dirty buffers efficiently without causing spikes.

• Adjust LGWR settings to avoid log write bottlenecks, which can stall user commits.

• Monitor wait events such as db file sequential read, db file scattered read, and log file sync to identify
contention points.
6. Using Oracle I/O Calibration Tool

Oracle provides an I/O Calibration Tool that simulates typical database I/O patterns and measures the storage
subsystem’s throughput and latency.

• Run this tool during off-peak hours to benchmark disk performance.

• Use results to determine if current storage meets workload demands or requires upgrades.

7. Monitoring with v$filestat and Other Views

Oracle dynamic views like v$filestat, v$session_wait, and v$waitstat provide insights into I/O activity and wait events:

• v$filestat shows I/O operations per file, helping spot hot files.

• v$session_wait tracks session-level waits, indicating I/O bottlenecks.

• Analyze these metrics regularly to spot trends and performance degradation.

8. Optimizing Storage Layout and RAID Configuration

Physical disk setup matters:

• Use RAID levels optimized for your workload (RAID 10 for OLTP, RAID 5 or 6 for read-heavy workloads).

• Ensure that disks aren’t overloaded with multiple unrelated files.

• Balance disk utilization to avoid hotspots that slow down I/O.

Concurrency and Lock Management in Oracle :-

What is Locking and Why It Matters

Oracle uses locks to maintain data consistency and prevent concurrent transactions from interfering with each other.
Locks protect data during transactions but can lead to contention if multiple sessions try to access the same resources
simultaneously.

Types of Locks and Latches

• Locks: Prevent conflicting DML (Data Manipulation Language) operations.

• Latches: Protect internal Oracle memory structures for brief periods.

• Excessive locking or latch contention can degrade performance by blocking sessions.

Monitoring Locks Using Oracle Views

Oracle provides views to monitor locking issues:

• v$lock: Shows current locks held or requested.

• v$session_wait: Displays wait events related to locks.

• DBA_BLOCKERS and DBA_WAITERS: Identify blocking and waiting sessions causing lock contention.

Avoiding Long-Running Transactions

Long transactions hold locks longer, increasing contention risks:

• Keep transactions short by committing or rolling back frequently.

• Avoid user interactions (like waiting for input) inside transactions.

Proper Transaction Design

Design transactions to:

• Access objects in consistent order to avoid deadlocks.

• Use appropriate isolation levels (READ COMMITTED vs SERIALIZABLE) based on consistency and concurrency
needs.

Deadlock Prevention and Resolution

Deadlocks occur when two or more sessions wait for each other’s locks:

• Oracle automatically detects and resolves deadlocks by rolling back one session.

• Analyze deadlock graphs (trace files) to identify root causes and fix SQL or transaction design.

Reducing Lock Contention with Optimized Queries

Poorly designed queries that scan or lock large amounts of data increase contention:

• Use selective WHERE clauses and indexes to limit locked rows.

• Avoid locking entire tables unless necessary.

Using Row-Level Locking Instead of Table Locks

Oracle uses row-level locking by default, which reduces contention compared to locking entire tables:

• Ensure your SQL and transactions allow row-level locking.

• Avoid explicit LOCK TABLE statements unless justified.

Understanding Wait Events Related to Locks

Wait events such as enq: TX - row lock contention indicate blocking caused by row locks. Monitoring and minimizing
such waits improve concurrency.

Lock-Free Read Consistency

Oracle’s multi-version concurrency control allows readers to access consistent data without blocking writers, minimizing
read locks and improving concurrency.

Managing Latch Contention

Latches are lightweight locks on internal memory structures:

• High latch contention can be diagnosed using v$latch and v$latchholder.

• Tune application or schema to reduce rapid access to same internal structures.

Tools and Best Practices for Lock and Concurrency Monitoring

• Use Enterprise Manager or Oracle Performance Hub for graphical lock and wait analysis.

• Regularly review locking reports and session activity.

• Educate developers and DBAs on best practices to avoid common locking pitfalls.

Summary

Efficient Oracle performance depends heavily on tuning I/O and storage configuration as well as managing concurrency
effectively. Leveraging ASM, separating files physically, enabling direct path I/O, and monitoring wait events optimizes
I/O throughput. Meanwhile, understanding and controlling locking behavior, avoiding long transactions, and monitoring
waits help maintain concurrency without contention. Combining these tuning strategies ensures a responsive, scalable
Oracle database.

.
Inside Oracle’s Brain: How AWR and ADDM Power
Intelligent Performance Tuning

Performance tuning in Oracle isn't just about fixing slow queries—it's about understanding the system as a whole. Two
of Oracle's most powerful diagnostic tools for this purpose are AWR (Automatic Workload Repository) and ADDM
(Automatic Database Diagnostic Monitor). Together, they form the foundation of Oracle's self-diagnostic and tuning
framework, offering deep insight into system performance over time.

What is AWR?

The Automatic Workload Repository (AWR) is a built-in performance monitoring feature in Oracle that collects and
stores system statistics automatically at regular intervals—by default, every 60 minutes. Each data capture is called a
snapshot, and these snapshots contain rich information about how the database is performing: CPU usage, memory
activity, disk I/O, wait events, SQL execution stats, and more.

Over time, these snapshots form a historical baseline that allows DBAs to compare database performance between
different periods. This is particularly useful when troubleshooting intermittent issues or analyzing the impact of
configuration changes.

AWR reports are essential in identifying:

• Top SQL statements consuming the most resources (CPU, I/O, elapsed time).

• Wait events that show where the database is spending time (e.g., I/O, locks, latches).

• Instance activity stats such as buffer cache efficiency, redo rates, and parsing.

• I/O statistics for datafiles and tablespaces to spot storage bottlenecks.

• Memory usage patterns, helping tune SGA and PGA components effectively.

You can generate AWR reports via Oracle Enterprise Manager (OEM) or command-line scripts such as awrrpt.sql. These
reports compare two snapshots and generate an easy-to-follow summary of performance trends and anomalies.

What is Active Session History (ASH) ?

Unlike AWR, which captures data in hourly snapshots, ASH samples session activity every second and retains data in
memory for a recent time window (typically the last 30–60 minutes, depending on workload and memory size).

ASH is ideal for:

• Investigating short-term or intermittent issues that don’t align with snapshot times.

• Analyzing session waits, blocking, and active SQL in near-real-time.

 • Identifying concurrency problems, such as lock contention or enqueue waits.

• Correlating performance drops to specific users, SQLs, or application modules.

ASH reports show what active sessions were doing, what they were waiting on, and how frequently—allowing you to
quickly zero in on hot spots.

You can generate ASH reports using scripts like ashrpt.sql, or query views such as v$active_session_history and
dba_hist_active_sess_history for deeper custom analysis.

What is ADDM?

The Automatic Database Diagnostic Monitor (ADDM) takes AWR data a step further by analyzing it and offering
actionable tuning recommendations. Every time a snapshot is taken, ADDM processes the data and identifies the root
causes of performance issues.

ADDM is particularly helpful because it doesn’t just highlight problems—it prioritizes them based on impact and offers
solutions, such as:

• Reducing resource-intensive SQL queries.

• Adding missing indexes or gathering stale statistics.

• Adjusting memory parameters or configuration settings.

• Identifying I/O or concurrency bottlenecks.

ADDM considers CPU usage, wait events, I/O, memory, and contention issues, giving a holistic picture of what's wrong
and how to fix it. This saves DBAs countless hours of manual analysis and guesswork.

Why Use AWR, ADDM, and ASH?

In modern Oracle environments, performance tuning isn’t a luxury—it’s a requirement. Applications need to run faster,
databases must scale under load, and users expect instant responses. To meet these demands, Oracle offers a powerful,
built-in performance diagnostics suite: AWR (Automatic Workload Repository), ADDM (Automatic Database Diagnostic
Monitor), and ASH (Active Session History). These tools form the backbone of proactive and reactive database tuning
and are critical for ensuring long-term stability, scalability, and responsiveness.

Unlike traditional ad hoc monitoring, these tools provide systematic, time-aware, and actionable insights into how your
database is behaving—both in real time and over historical baselines.
Why They’re Indispensable:

1. Proactive Issue Detection Before Users Notice

AWR collects system performance data every hour, allowing DBAs to detect patterns such as rising wait times,
abnormal SQL behavior, or I/O saturation early. Instead of reacting to user complaints, you can address potential
slowdowns before they impact the business.

2. Automated Root Cause Identification

When performance does degrade, ADDM analyzes AWR snapshots to pinpoint the exact cause—whether it’s a
high-CPU SQL statement, excessive parsing, redo log waits, or latch contention. You don’t need to sift through
dozens of system views manually—ADDM gives you ranked recommendations for the most impactful fixes.

3. Real-Time Session-Level Analysis with ASH

ASH captures session activity every second and stores it in memory. This lets you drill into what users were
doing during spikes—what queries were running, what they were waiting on, and what modules or programs
were involved. It’s ideal for diagnosing short-term or intermittent performance issues that don’t show up
clearly in hourly AWR reports.

4. Historical Baselines for Trend Analysis

AWR snapshots serve as a rich performance archive. You can compare how the database behaved last week
versus today—or how it performed before and after a patch, deployment, or schema change. This is critical for
validating the impact of tuning efforts or catching regressions early.

5. Top SQL Identification and Tuning Focus

AWR surfaces the SQL statements consuming the most CPU, I/O, or elapsed time. You get visibility into
execution plans, number of executions, buffer gets, and more. ADDM complements this by telling you if these
SQLs need rewriting, indexing, or plan management. Together, they ensure your tuning effort targets the
queries that matter most.

6. Concurrency and Wait Event Diagnosis

ASH and AWR show detailed wait event analysis—buffer busy waits, enqueue waits, log file sync, direct path
reads, etc. This allows you to diagnose concurrency issues, locking problems, and contention for system
resources. ASH even lets you see which sessions were blocking or being blocked in real time.

7. Impact Validation for Changes and Tuning

After implementing a fix (e.g., adding an index, changing a hint, adjusting memory), AWR lets you see the
measurable effect: Did CPU usage drop? Did I/O improve? Did the SQL plan become more efficient? This makes
performance tuning data-driven, not guesswork.

8. Supportability and SR-Readiness

Oracle Support often requests AWR, ADDM, and ASH reports as part of SR (Service Request) triage. Having these
reports already captured improves your ability to get timely, accurate support and build audit trails and RCA
documentation internally.

9. ASH: Pinpointing Performance Spikes

When users report, “The system was slow 10 minutes ago,” AWR won’t help—you need ASH. ASH lets you zoom
in on second-by-second activity, so you can see exactly what was happening during a short-lived performance
problem.
10. Lightweight and Built-In
These tools are part of Oracle’s Diagnostic and Tuning Packs. They run automatically with minimal performance
overhead and don’t require installing third-party agents or collectors. This makes them ideal for production
environments where minimal disruption is essential.

11. SQL Plan Change Detection

AWR stores execution plans over time, so you can spot if a query’s plan changed suddenly (e.g., due to stale
stats or a dropped index). ASH helps show when plan changes correlate with spikes in response time or wait
events.

12. Workload Characterization and Sizing

AWR reports give insights into workload types—OLTP vs. batch, CPU-intensive vs. I/O-heavy, read vs. write
balance. This helps infrastructure teams size hardware and storage correctly, avoiding over- or under-
provisioning.

13. Drill-Down from Symptoms to Cause

You can start from “CPU usage is high” in AWR, use ADDM to find the top SQLs, then use ASH to find the exact
user sessions, SQL IDs, and program modules responsible. This end-to-end traceability accelerates tuning and
accountability.

14. Capacity Planning and Forecasting

Long-term AWR data helps identify growth trends in data volume, workload intensity, or system usage. This is
vital for future-proofing your infrastructure with evidence-based capacity plans.

15. Enabling SLA Monitoring

With predictable baselines, you can detect violations of SLAs (Service Level Agreements)—for example, queries
that consistently exceed allowed execution times or throughput metrics.

16. Developer Collaboration

ASH and AWR outputs can be shared with developers to fine-tune queries, spot bad coding practices (e.g.,
cartesian joins, full table scans), and validate whether application changes improve performance.

17. Storage and I/O Bottleneck Detection

AWR provides detailed I/O stats at the file, tablespace, and object level. You can identify which datafiles or LUNs
are overloaded and if redo logs or temp usage are causing stalls.

18. Plan Evolution and Regression Prevention

Combined with SQL Plan Baselines, AWR and ADDM help you detect and prevent performance regressions due
to optimizer plan changes. You get early warning when execution times begin to drift.

19. Visualization with OEM (Enterprise Manager)

Oracle Enterprise Manager uses AWR, ADDM, and ASH data to offer graphical dashboards, heatmaps, and
alerts. This makes diagnostics more accessible to junior DBAs and managers alike.

20. Foundational for Automation and AI Ops

Many automated Oracle tuning tools, such as SQL Tuning Advisor, rely on AWR and ASH data. As Oracle moves
towards AI-driven database self-tuning, these tools will remain the core telemetry providers.
In summary

AWR tells you what happened, and ADDM tells you why it happened and how to fix it, AWR and ADDM transform raw
database activity into structured, prioritized, and actionable insights. They reduce the time to resolve issues, help avoid
future problems, and support consistent performance tuning practices across teams. Every Oracle DBA—especially in
production or critical environments—should make them part of their regular performance toolkit. If you're tuning Oracle
without AWR, ADDM, and ASH, you're flying blind. Together, they provide depth, clarity, and confidence to performance
management. Make reviewing their outputs a regular habit—not just when there's a crisis—and you'll build a system
that's not only fast but resilient, scalable, and supportable.

Overview of Best Practices for Performance

Tuning in Oracle

Performance tuning in Oracle databases is both an art and a science. While Oracle provides numerous built-in tools and
automated features to assist with performance optimization, understanding core tuning principles and applying them
consistently is key to building a high-performing system. Whether you’re working with OLTP or OLAP workloads, these
best practices will help you identify bottlenecks, improve responsiveness, and ensure scalability.

Below are 30 essential best practices for effective performance tuning in Oracle, each explained in detail for real-world
applicability:

1. Understand the Workload Profile

Start by classifying your workload—OLTP, OLAP, or hybrid. This helps prioritize tuning areas such as transaction
throughput vs. query performance.

2. Keep Optimizer Statistics Fresh

Use DBMS_STATS to gather accurate and timely statistics. Stale stats mislead the Cost-Based Optimizer (CBO), resulting
in poor execution plans.

3. Use Bind Variables for Reusability

Bind variables reduce hard parsing and improve plan reuse. They also protect against SQL injection and reduce shared
pool fragmentation.

4. Minimize Full Table Scans

Full scans are costly unless the table is small. Ensure that indexes are used for selective queries. Use the INDEX hint
cautiously to enforce index usage if needed.
5. Create the Right Indexes

Create indexes based on WHERE clauses, JOIN columns, and ORDER BY operations. Use bitmap indexes for low-
cardinality data and composite indexes for multi-column filters.

6. Monitor Execution Plans Continuously

Use tools like DBMS_XPLAN.DISPLAY_CURSOR, SQL Developer Autotrace, and AWR to compare execution plans over
time and detect regressions.

7. Avoid Over-Indexing

Too many indexes slow down INSERT/UPDATE/DELETE operations. Remove unused or redundant indexes after verifying
with v$object_usage.

8. Use SQL Plan Baselines

Lock in known-good plans to prevent regressions after stats refreshes or database upgrades. This ensures stability in SQL
execution.

9. Use SQL Tuning Advisor and SQL Access Advisor

These advisors analyze poorly performing SQL and suggest improvements, including statistics updates, indexes, and SQL
rewrites.

10. Partition Large Tables

Use range, list, or hash partitioning to manage large data volumes. Partitioning improves performance and simplifies
maintenance.

11. Implement Parallel Execution for Large Queries

Enable parallelism for resource-heavy queries and ETL jobs. Monitor using v$pq_sysstat and adjust
PARALLEL_MAX_SERVERS.

12. Use Materialized Views for Aggregates and Joins

Materialized views precompute results and refresh periodically, reducing runtime load for reporting queries.

13. Use AWR and ADDM Regularly

Generate AWR reports to identify high-load SQL, top wait events, and bottlenecks. Use ADDM for actionable
recommendations based on AWR data.

14. Leverage ASH (Active Session History) for Real-Time Insight

ASH provides session-level history, allowing you to trace session waits, blocking sessions, and time-consuming
operations during specific windows.

15. Tune with Wait Events in Mind

Use v$session, v$system_event, and v$session_wait to detect bottlenecks like "db file sequential read" (index I/O) or
"log file sync" (commit latency).
16. Optimize Redo and Undo Configuration

Size redo logs to avoid frequent log switches. Tune undo tablespaces and retention for long queries and rollback
operations.

17. Reduce Latch and Mutex Contention

High latch contention in the shared pool or library cache can degrade performance. Use bind variables and avoid
excessive parsing.

18. Optimize Memory with SGA and PGA Tuning

Monitor v$sgainfo and v$pga_target_advice to allocate memory efficiently. Set appropriate values for SGA_TARGET,
PGA_AGGREGATE_TARGET, and DB_CACHE_SIZE.

19. Avoid Fragmentation in TEMP Tablespace

Large sorts or hash joins may spill to disk. Monitor and resize temporary tablespaces accordingly. Use
TEMP_UNDO_ENABLED = TRUE for temporary undo.

20. Use Direct Path Reads/Writes for Bulk Operations

Enable direct path for data loads and large table scans to bypass buffer cache and reduce CPU overhead.

21. Configure I/O Subsystems Properly

Distribute redo, temp, and datafiles across ASM disk groups or separate storage tiers. Use
DBMS_RESOURCE_MANAGER.CALIBRATE_IO to benchmark.

22. Reduce Log File Contention

Increase redo log size, avoid frequent commits, and place redo logs on fast storage to reduce wait times on log file sync.

23. Optimize Checkpointing and DBWR Activity

Tune FAST_START_MTTR_TARGET and DB_WRITER_PROCESSES to control recovery time and I/O load during
checkpoints.

24. Avoid Hot Blocks

Identify blocks accessed frequently by multiple sessions using v$bh and spread load across partitions or hash-subdivided
data.

25. Use PL/SQL Efficiently

Minimize context switching between SQL and PL/SQL. Use bulk operations (BULK COLLECT, FORALL) and avoid row-by-
row processing.

26. Batch Transactions and Commits

Frequent commits create redo overhead. Batch DML operations to reduce redo and improve efficiency.
27. Tune Connection Pooling

Use efficient connection pooling from the application tier (WebLogic, JDBC UCP) to reduce login/logout overhead and
session churn.

28. Monitor Blocking Locks and Deadlocks

Use DBA_BLOCKERS, DBA_WAITERS, and v$locked_object to resolve session-level blocking and deadlocks early.

29. Use Baselines and Snapshots for Comparison

Capture performance baselines using AWR or custom tools. Compare pre/post-deployment performance to validate
tuning impact.

30. Document and Automate Tuning Workflows

Keep a tuning playbook for your environment: SQL baselines, parameter settings, stats collection jobs, and known issue
resolutions. Automate common tuning tasks using scripts or Enterprise Manager.

Essential Oracle Dynamic Performance Views for Tuning

Below is a list of 30 of the most commonly used Oracle dynamic performance (V$) views for performance tuning. These
views provide insight into various aspects of your Oracle instance — from system-level statistics and SQL execution
details to session waits and I/O behavior. Each view is briefly explained to help you understand its role in the tuning
process.

Note: Many of these views require proper privileges and may need an Oracle Diagnostic Pack license to query.

1. V$DATABASE

Provides basic information about the database such as name, creation date, and current open mode. Useful for quickly
validating environment settings.

2. V$INSTANCE

Shows details about the current instance including status, startup time, and instance role. Essential for understanding
instance-level behavior.

3. V$PARAMETER

Lists the initialization parameters currently in effect. Adjusting parameters based on performance data is a crucial tuning
step.
4. V$OPTION

Displays which options and features are enabled in the database. Helps verify whether certain performance-enhancing
options are active.

5. V$STATNAME

Provides the names and descriptions of dynamic performance statistics. Acts as a dictionary for counters reflected in
other V$ views.

6. V$SYSSTAT

Contains cumulative system-wide statistics since the instance started. Useful for examining overall system performance
trends and baselining.

7. V$SESSTAT

Shows session-specific statistics. Helpful for correlating resource usage with individual sessions and identifying outliers.

8. V$SESSION

Offers detailed information about active and inactive sessions, including session status, SQL_ID, and identifiers for
troubleshooting.

9. V$PROCESS

Provides information about Oracle processes, including memory and CPU usage for background and user processes.

10. V$SESSION_WAIT

Displays current wait events for each session. Critical when diagnosing why a particular session is slow.

11. V$SYSTEM_EVENT

Aggregates wait event data across the entire instance — helping pinpoint system-wide bottlenecks like I/O, network, or
contention issues.

12. V$SQLAREA

Aggregates performance statistics on SQL statements across the instance. Helps identify frequently executed and
resource-intensive SQL.

13. V$SQL

Details current SQL statements and their execution statistics. Used to analyze active SQL and understand execution
performance.

14. V$SQL_PLAN

Provides the execution plan for SQL queries. Reviewing it reveals how the optimizer accesses data and whether indexes
are utilized.
15. V$SQL_PLAN_STATISTICS

Reports execution plan statistics after query execution, showing actual costs and row counts versus expected values.

16. V$SQL_MONITOR

Offers real-time monitoring data for long-running or resource-intensive SQL. Valuable for spotting performance issues in
real time.

17. V$ACTIVE_SESSION_HISTORY (ASH)

Provides a sampled history of active sessions, revealing transient bottlenecks that might be missed in averaged data.

18. V$FILESTAT

Shows statistics about file-level I/O operations, tracking read and write performance of datafiles.

19. V$IOSTAT_FILE

Provides granular I/O statistics focused on specific files, helping identify disk bottlenecks.

20. V$TEMPSTAT

Reports statistics on temporary operations and space usage in temporary tablespaces. Key for diagnosing sorts that spill
to disk.

21. V$LATCH

Contains information about latches, low-level serialization mechanisms protecting shared memory. Excessive contention
indicates concurrency issues.

22. V$LATCHHOLDER

Identifies sessions currently holding latches. Useful when diagnosing latch contention problems.

23. V$LOCK

Displays all locks held by sessions. Helps identify blocking sessions and inter-session dependencies.

24. V$RESOURCE_LIMIT

Shows current usage and max values for system resources (e.g., sessions, processes). Assists with capacity planning and
resource allocation.

25. V$UNDOSTAT

Reports undo segment usage and historical undo activity, important for tuning undo performance and sizing undo
tablespaces.

26. V$SEGMENT_STATISTICS

Gathers I/O and operational statistics per database segment (tables or indexes). Identifies “hot” or underperforming
segments.
27. V$SYS_TIME_MODEL

Provides detailed CPU time usage statistics for the instance. Helps understand where CPU time is spent — user code,
system, or waits.

28. V$OSSTAT

Offers a snapshot of operating system statistics as seen by Oracle. Correlates database performance with physical
resource limits.

29. V$EVENT_NAME

Lists all wait events known to Oracle with classifications. Helps map wait events observed in other views to root causes.

30. V$SESSION_EVENT

Records wait event counts at the session level over time. Essential for understanding changes in session behavior
historically.

How to Use These Views for Effective Tuning

• Start with system-wide views like V$SYSSTAT and V$SYSTEM_EVENT to detect overall anomalies.

• Drill down to session-level and SQL-focused views such as V$SESSION, V$SQLAREA to isolate problematic queries
or sessions.

• Use historical data from V$ACTIVE_SESSION_HISTORY (ASH) to establish baselines and understand transient
issues.

• Compare metrics before and after tuning changes to verify improvements and avoid regressions.

• Correlate wait events with resource usage (e.g., high I/O waits in V$SYSTEM_EVENT combined with V$FILESTAT
data) to guide targeted tuning efforts.

• Investigate latch contention using V$LATCH and V$LATCHHOLDER to improve concurrency.

Further Exploration

• Explore global V$ views (GV$) if using Oracle RAC to analyze cluster-wide behavior.

• Combine these views with Automatic Workload Repository (AWR) and Oracle Enterprise Manager (OEM) reports
for deeper diagnostics.

• Regularly querying and understanding these views builds intuition for spotting and solving performance
problems efficiently.
 Final Advice: Driving Oracle Performance in the
Real World

Performance tuning isn’t just a theoretical exercise—it’s mission-critical in real production environments where
downtime or slowness directly affects business outcomes. In sectors like banking and pharmaceuticals, where data
throughput, accuracy, and regulatory compliance are paramount, Oracle performance tuning plays a pivotal role in
ensuring that systems are fast, reliable, and scalable.

Here’s how the practices you’ve learned translate to real-world value:

1. Banking Sector: Preventing Transaction Delays

In high-volume banking systems, even a minor increase in query response time can affect thousands of transactions. For
example:

• Use Case: A national bank noticed delayed ATM transactions during peak hours.

• Resolution: By using AWR/ADDM reports, they discovered slow I/O due to poor index usage on the transaction
logs. Creating the right composite indexes and tuning the SQL eliminated the bottleneck.

• Impact: Transaction time dropped from 7 seconds to under 1.5 seconds—boosting customer satisfaction and
reducing timeout failures.

2. Pharma Industry: Faster Clinical Data Processing

Clinical trial data is often processed in batches, and delays can result in regulatory setbacks.

• Use Case: A pharmaceutical company had nightly ETL jobs exceeding their batch window.

• Resolution: ASH and SQL Monitor identified inefficient full table scans. SQL was rewritten using bind variables,
and optimizer statistics were updated.

• Impact: Batch jobs now complete 40% faster, ensuring timely reporting and compliance with FDA regulations.
3. Retail: Handling Holiday Season Load

E-commerce and retail applications need to scale fast during peak shopping periods.

• Use Case: During Black Friday, a retail platform experienced slow product searches and checkout processing.

• Resolution: SQL tuning and memory reconfiguration (SGA/PGA tuning) helped the platform handle 3x the traffic
with no degradation in user experience.

• Impact: Improved customer retention and conversion during the busiest shopping period.

KEY TAKEAWAYS

• Tune Before You Scale: Don’t just throw more hardware at the problem—optimize your SQL, memory, and I/O
usage first.

• Use Oracle’s Diagnostics: Tools like AWR, ADDM, and ASH provide a treasure trove of actionable insights. Learn
to read and interpret these reports regularly.

• Benchmark and Revalidate: Performance is not static. Regular benchmarking ensures that new releases,
patches, or changes don’t unknowingly degrade performance.

• Automate Where Possible: Use SQL Plan Management, Automatic Statistics Collection, and Resource Manager
to reduce manual intervention and maintain predictability.

Effective performance tuning is part art, part science. The principles, tools, and strategies discussed in this guide are
field-tested and proven across industries. When used consistently, they not only fix performance problems but help
build resilient, scalable, and efficient systems. Let this guide be your foundation—but continue learning, testing, and
tuning. The Oracle ecosystem evolves, and so should your skills.