AWR is the infrastructure that provides services to Oracle Database 11g components to collect,
maintain, and utilize statistics for problem detection and self-tuning purposes.
The AWR infrastructure consists of two major parts:
• An in-memory statistics collection facility that is used by various components to collect
statistics. These statistics are stored in memory for performance reasons. Statistics stored in
memory are accessible through dynamic performance (V$) views.
• AWR snapshots represent the persistent portion of the facility. The AWR snapshots are
accessible through data dictionary (DBA) views and Database Control.
Statistics are stored in persistent storage for several reasons:
• The statistics need to survive instance crashes.
• Historical data for baseline comparisons is needed for certain types of analysis.
• Memory overflow: When old statistics are replaced by new ones due to memory shortage,
the replaced data can be stored for later use.
The memory version of the statistics is transferred to disk on a regular basis by a background
process called MMON (Manageability Monitor).
With AWR, the Oracle database server provides a way to capture historical statistics data
automatically, without the intervention of DBAs.
The workload repository is a collection of persistent system performance statistics owned by
SYS. The workload repository resides in the SYSAUX tablespace and is one of the main
SYSAUX occupants.
A snapshot is a set of performance statistics captured at a certain time. Snapshots are used for
computing the rate of change of a statistic. Each snapshot is identified by a snapshot sequence
number (snap_id) that is unique in the workload repository.
By default, snapshots are generated every 60 minutes. You can adjust this frequency by
changing the snapshot INTERVAL parameter. Because internal advisories rely on these
snapshots, be aware that adjustment of the interval setting can affect diagnostic precision. For
example, if INTERVAL is set to 4 hours, you may miss spikes that occur within 60-minute
intervals.
In a Real Application Clusters environment, each snapshot spans all nodes in a cluster.
Snapshots for data in each node share the same snap_id, differentiated by their instance IDs.
Snapshots in Real Application Clusters are captured at roughly the same time.
You can take manual snapshots by using Database Control. Taking manual snapshots is
supported in conjunction with the automatic snapshots that the system generates. Manual
snapshots are expected to be used when you want to capture the system behavior at two specific
points in time that do not coincide with the automatic schedule.
maintain, and utilize statistics for problem detection and self-tuning purposes.
The AWR infrastructure consists of two major parts:
• An in-memory statistics collection facility that is used by various components to collect
statistics. These statistics are stored in memory for performance reasons. Statistics stored in
memory are accessible through dynamic performance (V$) views.
• AWR snapshots represent the persistent portion of the facility. The AWR snapshots are
accessible through data dictionary (DBA) views and Database Control.
Statistics are stored in persistent storage for several reasons:
• The statistics need to survive instance crashes.
• Historical data for baseline comparisons is needed for certain types of analysis.
• Memory overflow: When old statistics are replaced by new ones due to memory shortage,
the replaced data can be stored for later use.
The memory version of the statistics is transferred to disk on a regular basis by a background
process called MMON (Manageability Monitor).
With AWR, the Oracle database server provides a way to capture historical statistics data
automatically, without the intervention of DBAs.
The workload repository is a collection of persistent system performance statistics owned by
SYS. The workload repository resides in the SYSAUX tablespace and is one of the main
SYSAUX occupants.
A snapshot is a set of performance statistics captured at a certain time. Snapshots are used for
computing the rate of change of a statistic. Each snapshot is identified by a snapshot sequence
number (snap_id) that is unique in the workload repository.
By default, snapshots are generated every 60 minutes. You can adjust this frequency by
changing the snapshot INTERVAL parameter. Because internal advisories rely on these
snapshots, be aware that adjustment of the interval setting can affect diagnostic precision. For
example, if INTERVAL is set to 4 hours, you may miss spikes that occur within 60-minute
intervals.
In a Real Application Clusters environment, each snapshot spans all nodes in a cluster.
Snapshots for data in each node share the same snap_id, differentiated by their instance IDs.
Snapshots in Real Application Clusters are captured at roughly the same time.
You can take manual snapshots by using Database Control. Taking manual snapshots is
supported in conjunction with the automatic snapshots that the system generates. Manual
snapshots are expected to be used when you want to capture the system behavior at two specific
points in time that do not coincide with the automatic schedule.
No comments:
Post a Comment