[AWR report generated by Oracle database]

/home/oracle file generation path





Automatic Workload Repository (AWR)

The origin of AWR:
    Oracle before 10g: the user's connection will generate a session, and the current session record will be saved in v$session; the session in the waiting state will A copy is placed in v$session_wait. When the connection is
 disconnected, its original connection information will be deleted in v$session and v$session_wait; oracle10g and later retain the information in v$session_wait, and
add v$active_session_history (ASH) view , record the last 10 waiting events in v$session_wait for each active session.

    The sampling data of ASH is stored in memory. The memory space allocated to ASH is limited. When the allocated space is full, the old records will be overwritten; and after the database is restarted, all the
ASH information will disappear. In this way, it is impossible to detect the performance of the oracle in the long term. In Oracle10g, a method to permanently retain ASH information is provided, which is AWR.
   
    Since it is very time-consuming and space-consuming to save all the information in ASH, the strategy adopted by AWR is to sample v$active_session_history once an hour, save the information to disk
, and keep it for 7 days, after 7 days the old records will be will be overwritten. This sampling information is stored in the view wrh$_active_session_history. The sampling frequency (1 hour) and retention time
(7 days) can be adjusted according to the actual situation, which provides DBAs with a more effective system monitoring tool.

1. AWR enabled

    By default, Oracle enables database statistics collection (that is, enables AWR). Whether to enable AWR is controlled by the initialization parameter STATISTICS_LEVEL.

The current value of STATISTICS_LEVEL can be displayed through the SHOW PARAMETER command :

     SQL> SHOW PARAMETER STATISTICS_LEVEL

The execution result of the SQL statement is:
NAME TYPE VALUE
------------------------ ------------ ------------- ----------------------------- ---
statistics_level string TYPICAL

If the value of STATISTICS_LEVEL is TYPICAL or ALL, it means that AWR is enabled; if the value of STATISTICS_LEVEL is BASIC, it means that AWR is disabled.

Introduction to the initialization parameter statistics_level:
The behavior of AWR is affected by the parameter STATISTICS_LEVEL. This parameter has three values:
*BASIC: calculation and derivation of awr statistics off. Only a small number of database statistics are collected.
*TYPICAL: Default value. Only partial statistics are collected. They represent the behavior required for typical monitoring oracle databases.
*ALL : All possible statistics are captured. And there is some information about the operating system. This level of capture should be done in rare cases, such as you It is only used when more sql diagnostic information is required.

2. Snapshot (SNAPSHOT)
   Every hour, the memory monitoring process (MMON) automatically collects statistical information and stores the information in the load library. A sampling is a snapshot. To save space, the collected data is
automatically cleared after 7 days. The frequency and retention time of snapshots can be modified by the user.
--View the frequency and retention time of snapshots (the default is sampling every 1 hour, and the retention time of sampling information is 7 days)
 select * from dba_hist_wr_control;
 select DBID, SNAP_INTERVAL, SNAPINT_NUM, RETENTION from wrm$_wr_control; --modify
the frequency of snapshots and retention time (in minutes)
exec dbms_workload_repository.modify_snapshot_settings(interval=>60, retention=>7*24*60);
Users can also use the following command to manually sample (manually generate snapshots):
    BEGIN 
    DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT (); 
    END;
Manually delete snapshots in the specified range
  begin
  dbms_workload_repository.drop_snapshot_range(low_snap_id => 3965, high_snap_id => 3966, dbid => 3437504306);
  end; --Check
 how many snapshots there are
 select count(1) from wrh$_active_session_history;
 select count(1) from dba_hist_active_sess_history;
By querying the view DBA_HIST_SNAPSHOT, you can know which snapshots are generated in the system.
select * from DBA_HIST_SNAPSHOT;
3. Sample data storage location
    These sample data are stored in the SYSAUX tablespace, and are named in the format of WRM$_* and WRH$_*. The former type stores metadata information such as checked databases and collected snapshots, and
the latter type holds the actual collected statistics.
select table_name from dba_tables where table_name like 'WRM$%';
TABLE_NAME
-----------------------
WRM$_WR_CONTROL
WRM$_SNAP_ERROR
WRM$_SNAPSHOT
WRM$_DATABASE_INSTANCE
WRM $_BASELINE
When the SYSAUX tablespace is full, AWR will automatically overwrite the old information and record a related information in the warning log:
ORA-1688: unable to extend table SYS.WRH$_ACTIVE_SESSION_HISTORY partition WRH$_ACTIVE_3533490838_1522 by 128 in tablespace SYSAUX
select table_name from dba_tables where table_name like 'WRH$%';
4. Setting baseline
 4.1 Creating a baseline
    is a mechanism , so that you can mark the snapshot information set at important times. A baseline is defined between a pair of snapshots, identified by their snapshot sequence numbers. Each
baseline has one and only one pair of snapshots. A typical performance tuning practice begins by collecting a baseline set of metrics, making changes, and then collecting another baseline set. The two sets can be compared to check
the effect of the changes made. In AWR, the same type of comparison can be performed on existing captured snapshots.
    Suppose a named apply_interest runs between 2:00 AM and 4:00 AM, corresponding to snapshot IDs 4150 to 4151. We can define
a baseline named apply_interest_1 for these snapshots:
SQL> exec dbms_workload_repository.create_baseline(4150, 4151, 'apply_interest_1');
this will number the snapshots from 4150 to 4151 as part of the baseline specified above. To view an existing baseline:
SQL> select *from dba_hist_baseline;
 DBID BASELINE_ID BASELINE_NAME START_SNAP_ID START_SNAP_TIME END_SNAP_ID END_SNAP_TIME
---------- ----------- -------------------- -- ----------- -------------------------------- ------- ---- -------------------------------
3437504306 1 apply_interest_1 4150 07-Mar-11 03.00.47.627 AM 4151 07-Mar-11 04.00.12.567 AM
SQL> select *from wrm$_baseline;
 
DBID BASELINE_ID BASELINE_NAME START_SNAP_ID END_SNAP_ID
---------- ----------- ----- ------------------------- ------------- -----------
3437504306 1 apply_interest_1 4150 4151
After some adjustment steps, we can create another baseline—let’s say it’s named apply_interest_2 (2-4pm), and then compare metrics only for those snapshots related to these two baselines.
SQL> exec dbms_workload_repository.create_baseline(4162, 4163, 'apply_interest_2');
 
Separating the snapshots in just a few sets like this helps to study the effect of tuning on performance metrics.

4.2
    Use drop_baseline() to drop the baseline after removing the baseline analysis; snapshots will be retained (can also be cascaded). Additionally, baseline-related snapshots are not purged when the purge routine begins to delete old snapshots,
allowing further analysis.
To drop a baseline:
SQL> exec dbms_workload_repository.drop_baseline(baseline_name=>'apply_interest_1', cascade=>false);
 
SQL> select *from wrh$_active_session_history where snap_id in (4150,4151);
 
SNAP_ID DBID INSTANCE_NUMBER SAMPLE_ID SAMPLE_TIME SESSION_ID ...
4150 3437504306 1 14900840 07-Mar-11 02.55.02.038 AM 162 ...  
4150 3437504306 1 14900200 07-Mar-11 02.44.21.942 AM 165 
...
4151 3437504306 1 14901980 07-00-11 03.14.02.213 AM ...   
4151 3437504306 1 14901790 07-March -11 03.10.52.183 165 ... 
4151 3437504306 1 14901490 07-March -11 03.05.52.138 167 ...
 
-- cascade delete (baseline and snapshot are deleted together)
SQL> exec dbms_workload_repository.drop_baseline(baseline_name=>'apply_interest_2', cascade=>true);
SQL> select *from wrh$_active_session_history where snap_id in (4162, 4163); Unselected
row
5. Generating AWR Reports

    Oracle can generate two types of AWR reports: text format and HTML format. The report interface in HTML format is more user-friendly. AWR reports are used to display data captured between two snapshots or two points in time

. The AWR report is actually a database health check-up table, which displays various indicators of database health.

    There are AWR reports for the entire database, AWR reports for an instance (in a cluster environment), and AWR reports for a single SQL statement. The AWR report is generated by running the SQL script that comes with Oracle

, but to generate different AWR reports, different scripts need to be run.

    -- To generate an AWR report for the entire database, run the script awrrpt.sql.

   @$ORACLE_HOME/rdbms/admin/awrrpt.sql

    -- To generate an AWR report for an instance, run the script awrrpti.sql.

   @$ORACLE_HOME/rdbms/admin/awrrpti.sql

    -- To generate an AWR report for a SQL statement, run the script awrsqrpt.sql.

   @$ORACLE_HOME/rdbms/admin/awrsqrpt.sql --Note

: $ORACLE_HOME represents Oracle's home directory.

Example: Generate an AWR report for the entire database. In this example, the Oracle home directory is /oracle/product/10.2.0/db_1/rdbms/admin

to run the script awrrpt.sql.

    SQL> @/oracle/product/10.2.0/db_1/rdbms/admin/awrrpt.sql

Select the type of report.

   1. Enter the value of report_type:  html

Select HTML in this example.

List the snapshots generated in the last two days (mainly to get the snapshot ID)

   1. Enter the value of num_days:  2 

                                                        Snap
Instance DB Name Snap Id Snap Started Level
------------ ------------ --------- --------- --------- -----
telemt TELEMT 4123 06 Mar 2011 00:00 1
                               4124 06 Mar 2011 01:01 1
....
                               4160 07 Mar 2011 13:00 1
                               4161 07 Mar 2011 14: 00 1

specifies the ID of the start snapshot and the ID of the end snapshot.

   1. Specify the Begin and End Snapshot Ids 
   2. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
   3 . Enter the value of begin_snap:   4123
   4. Begin Snapshot Id specified: 4123
   5. 
   6. Enter the value of end_snap:   4161
   7. End Snapshot Id specified: 4161

In this example, the ID of the starting snapshot is 4123, and the ID of the ending snapshot is 4161.

Specifies the name of the report.

    Enter the value of report_name:   myreport.html
   
Note: After entering the report name, press Enter and ORA-00904:: invalid identified value will appear
Solution: use the sys user to execute or authorize the user grant all on dbms_workload_repository to perfstat;