Performance Monitoring and Tuning
Performance Monitoring and Tuning focuses on measuring where time goes using AWR, ASH and V$ views, and interpreting waits rather than guessing at parameters.
Time model
DB time is the time foreground sessions spend in database calls: DB CPU plus non-idle wait time. If DB time exceeds elapsed time, sessions are running concurrently. AWR snapshots (hourly by default, eight days retained) feed reports and ADDM; ASH samples active sessions every second and answers what was happening at a given moment via V$ACTIVE_SESSION_HISTORY.
Where to look
V$SYSTEM_EVENT and V$SESSION_EVENT list waits; V$SQL and V$SQLSTATS give elapsed time, executions, buffer gets and disk reads per statement; V$SYSSTAT holds cumulative counters. Top waits point at a subsystem: db file sequential read means single-block index I/O; log file sync means commit latency; enq: TX - row lock contention means application locking.
Statistics
DBMS_STATS.GATHER_TABLE_STATS and the automatic maintenance job keep the optimizer informed; STALE_STATS in user_tab_statistics flags drift. SQL plan baselines prevent plan regressions; SQL Tuning Advisor and DBMS_SQLTUNE propose indexes, profiles or rewrites.
Worked example
Users complain at 09:00. The AWR top events show log file sync at 60 percent of DB time with an 8 ms average. That is commit wait, not a cache problem: check commit frequency in V$SYSSTAT, redo device latency and LGWR activity, then batch commits where possible. Raising db_cache_size would not help, because the diagnosis comes from the dominant wait event, not from a default parameter.
Traps
Reading elapsed time per execution without checking execution counts; comparing snapshots taken over different intervals; assuming a high buffer cache hit ratio means health; tuning SQL before verifying statistics are current; confusing DB time with wall-clock elapsed time.