Вы находитесь на странице: 1из 19

AWR - Automatic Workload Repository - Database - Database Skill

Página 1 de 2

AWR - Automatic Workload Repository

Tag: Parameters, DB Management, Report Category: Database Author: wang_66977 Date: 2010-07-23
Tag: Parameters, DB Management, Report
Category: Database
Author: wang_66977
Date: 2010-07-23

Archive, it is time to read ~ The AWR

To properly collect database statistics, the parameter statistics_level should be set to TYPICAL (the default) or ALL.

The Oracle database uses AWR for problem detection and analysis as well as for self-tuning. A number of different statistics are collected by the AWR including wait events, time model statistics, active session history statistics, various system and session-level statistics, object usage statistics, and information on the most resource- intensive SQL statements. Other Oracle Database 10g features use the AWR, including ADDM and the other advisors in Oracle Database 10g that we will discuss in this series of articles.

If you want to explore the AWR repository, feel free to do so. The AWR consists of a number of tables owned by the SYS schema and typically stored in the

SYSAUX tablespace (currently no method exists to move these objects to another tablespace). All AWR table names start with the identifier "WR." Following WR is

a mnemonic that identifies the type designation of the table followed by a dollar sign ($). AWR tables comewith three different type designations:

1.Metadata (WRM $) 2.Historical data (WRH $) 3.AWR tables related to advisor functions (WRI $)

Most of the AWR table names are pretty self-explanatory, such as WRM $ _SNAPSHOT or WRH $ _ACTIVE_SESSION_HISTORY.

Also Oracle Database 10g offers several DBA tables that allow you to query the AWR repository. The tables all start with DBA_HIST, followed by a name that describes the table. These include tables such as DBA_HIST_FILESTATS, DBA_HIST_DATAFILE, or DBA_HIST_SNAPSHOT.

Manually Managing the AWR

While AWR is meant to be automatic, provisions for manual operations impacting the AWR are available. You can modify the snapshot collection interval and retention criteria, create snapshots, and remove snapshots from the AWR. We will look at this process in more detail in the next few sections.

Manual snapshot collection and retention You can modify the snapshot collection interval using the dbms_workload_repository package. The procedure dbms_workload_repository.modify_snapshot_settings

is used in this example to modify the snapshot collection so that it occurs every 30 minutes, and retention of snapshot data is fixed at 10080 minutes:

- This causes the repository to refresh every 30 minutes

- And retain all data for 1 weeks.

Exec dbms_workload_repository.modify_snapshot_settings (retention => 10080, interval => 30);

(Setting the interval parameter to 0 will disable all statistics collection.)

To view the current retention and interval settings of the AWR, use the DBA_HIST_WR_CONTROL view. Here is an example of how to use this view:

SELECT * FROM dba_hist_wr_control;

DBIDAAAAAAAAAAAAA SNAP_INTERVALAAAAAAA RETENTIONAAAAAAAAAAAAAAAAAAAAA TOPNSQL ---------- AAAAAAAA -------------------- AAAAAAAA ------------------ ------- AAAAAAAA ---------- 4005531560 +00000 01:00:00.0 AAA +00007 00:00:00.0 AAAAAAAA DEFAULT

In this example, we see that the snapshot interval is every hour (the default), and the retention is set for seven days.

Creating or removing snapshots You can use the dbms_workload_repository package to create or remove snapshots. The dbms_workload_repository.create_snapshot procedure creates a manual snapshot in the AWR as seen in this example:

The EXEC dbms_workload_repository.create_snapshot;

You can see what snapshots are currently in the AWR by using the DBA_HIST_SNAPSHOT view as seen in this example:

SELECT snap_id, begin_interval_time, end_interval_time FROM dba_hist_snapshot ORDER BY 1;

SNAP_ID BEGIN_INTERVAL_TIMEAAAAAAAAAAA END_INTERVAL_TIME

-------------------------------------------------- --------------------

1 01-SEP-08 11.26.45.000 AMAAAAA 01-SEP-08 12.00.50.984 PM

2 01-SEP-08 12.00.50.984 PMAAAAA 01-SEP-08 01.00.55.991 PM

3 01-SEP-08 01.00.55.991 PMAAAAA 01-SEP-08 02.00.57.578 PM

4 01-SEP-08 02.00.57.578 PMAAAAA 01-SEP-08 03.00.59.208 PM

5 01-SEP-08 03.00.59.208 PMAAAAA 01-SEP-08 04.00.00.796 PM

6 01-SEP-08 04.00.00.796 PMAAAAA 01-SEP-08 05.00.02.407 PM

7 01-SEP-08 05.00.02.407 PMAAAAA 01-SEP-08 06.00.04.038 PM

8 01-SEP-08 06.00.04.038 PMAAAAA 01-SEP-08 07.00.05.639 PM

9 01-SEP-08 07.00.05.639 PMAAAAA 01-SEP-08 08.00.07.304 PM

Each snapshot is assigned a unique snapshot ID that is reflected in the SNAP_ID column. If you have two snapshots, the earlier snapshot will always have a smaller SNAP_ID than the later snapshot. The END_INTERVAL_TIME column displays the time that the actual snapshot was taken.

http://www.databaseskill.com/988105/

26/09/2015

AWR - Automatic Workload Repository - Database - Database Skill

Página 2 de 2

Sometimes you might want to drop snapshots manually. The dbms_workload_repository.drop_snapshot_range procedure can be used to remove a range of snapshots from the AWR. This procedure takes two parameters, low_snap_id and high_snap_id, as seen in this example:

EXEC dbms_workload_repository.drop_snapshot_range (low_snap_id => 1, high_snap_id => 4);

AWR automated snapshots

Oracle Database 10g uses a scheduled job, GATHER_STATS_JOB, to collect AWR statistics. This job is created, and enabled automatically when you create a new Oracle database under Oracle Database 10g. To see this job, use the DBA_SCHEDULER_JOBS view as seen in this example:

SELECT a.job_name, a.enabled, c.window_name, c.schedule_name, c.start_date, c.repeat_interval In FROM dba_scheduler_jobs a, dba_scheduler_wingroup_members b the dba_scheduler_windows c WHERE job_name = 'GATHER_STATS_JOB' And a.schedule_name = b.window_group_name And b.window_name = c.window_name;

You can disable this job using the dbms_scheduler.disable procedure as seen in this example:

Exec dbms_scheduler.disable ('GATHER_STATS_JOB');

And you can enable the job using the dbms_scheduler.enable procedure as seen in this example:

Exec dbms_scheduler.enable ('GATHER_STATS_JOB');

AWR Snapshot Reports

Oracle provides reports that you can run to analyze the data in the AWR. These reports are much like the statspack reports prior to Oracle Database 10g. There are two reports: awrrpt.sql and awrrpti.sql, which are available in the directory $ ORACLE_HOME / rdbms / admin.

The output of these reports is essentially the same, except that awrrpti.sql script allows you to define a specific instance to report on.

The reports are much like the statspack reports of old, in that you define a beginning and ending snapshot ID, and the output filename of the report. Additionally, you can opt to produce the report in either text format or HTML format.

AWR Baselines

It is frequently a good idea to create a baseline in the AWR. A baseline is defined by <Robert, should this be "by" or "as"> a range of snapshots that can be used to compare to other pairs of snapshots. The Oracle database server will exempt the snapshots assigned to a specific baseline from the automated purge routine. Thus, the main purpose of a baseline is to preserve typical runtime statistics in the AWR repository, allowing you to run the AWR snapshot reports on the preserved baseline snapshots at any time and compare them to recent snapshots contained in the AWR. This allows you to compare current performance (and configuration) to established baseline performance, which can assist in determining database performance problems.

In this section, you will learn how to create baselines, remove baselines, and how to use baselines.

Creating baselines You can use the create_baseline procedure contained in the dbms_workload_repository stored PL / SQL package to create a baseline as seen in this example:

EXEC dbms_workload_repository.create_baseline (start_snap_id => 1109, end_snap_id => 1111, baseline_name => 'EOM Baseline');

Baselines can be seen using the DBA_HIST_BASELINE view as seen in the following example:

SELECT baseline_id, baseline_name, start_snap_id, end_snap_id FROM dba_hist_baseline;

BASELINE_ID BASELINE_NAME START_SNAP_ID END_SNAP_ID ----------- AAAAAA --------------- AAAAAAAAA ------------- AAAAAAAAA -------- --- 1AAAAAAAAAAAAAAAAAA BaselineAAAAAAAAAAAAAA 1 AAAAAAAAAAAAAAAAAAAAAAA 5

In this case, the column BASELINE_ID identifies each individual baseline that has been defined. The name assigned to the baseline is listed, as are the beginning and ending snapshot IDs.

Removing baselines

You can remove a baseline using the dbms_workload_repository.drop_baseline procedure as seen in this example that drops the "EOM Baseline" that we just created.

EXEC dbms_workload_repository.drop_baseline (baseline_name => 'Baseline', Cascade => FALSE);

Note that the cascade parameter will cause all associated snapshots to be removed if it is set to TRUE; otherwise, the snapshots will be cleaned up automatically by the AWR automated processes.

http://www.databaseskill.com/988105/

snapshots will be cleaned up automatically by the AWR automated processes. http://www.databaseskill.com/988105/ 26/09/2015

26/09/2015

AWR (Automatic Workload Repository) - comparative report generator (2)! - Data

Página 1 de 3

AWR (Automatic Workload Repository) - comparative report generator (2)!

Tag: SQL, pair, DATABASE, report, html

Category: Database

Author: AIJIAAIADDFAFADFA

Date: 2011-03-04

Gestiona Organiza Crece Microsoft Dynamics AX ERP ¿Preparado?
Gestiona Organiza Crece
Microsoft Dynamics AX ERP
¿Preparado?

Baseline (Baseline):

Create a database comparison report, usually selected sample comparison of the two periods, and if we are able to create based on the normal operation of the database snapshot, in the event of a performance problem, it can be abnormal and normal comparison Differences between information. With baseline, the contrast between the AWR report will be more clear and effective.

01.

SQL> exec

dbms_workload_repository.create_baseline(start_snap_id=>90,end_snap_id=>95,baseline_name=> 'baseline01');

02.

 

03.

PL/SQL ?

04.

05.

SQL> select * from dba_hist_baseline;

 

06.

 

07.

DBID BASELINE_ID BASELINE_NAM START_SNAP_ID START_SNAP_TIME

END_SNAP_ID END_SNAP_TIME

08.

---------- ----------- ------------ ------------- ------------------------------ ----------- ------------------------------

09.

1293815896

1 baseline01

90 25-11-11 02.17.22.241

95 25-11-11 07.00.39.847

10.

 

11.

SQL> exec dbms_workload_repository.drop_baseline(baseline_name=>'baseline01',cascade=>true);

12.

13.

PL/SQL ?

14.

15.

SQL> select * from dba_hist_baseline;

 

Specified in the delete cascade => true, snapshot information will be deleted cascade! That is the AWR report alerts generated again will 90 to 95 of the snapshot information is not visible.

the awrddrpt.sql script compared to the same database two hours to generate detailed comparison reports provide a comparative analysis of!

script awrddrpi.sql can compare the two periods of the different databases, generate a detailed comparison report provides a comparative analysis of!

01.

[oracle@linux awr]$ sqlplus / as sysdba @?/rdbms/admin/awrddrpt.sql

--AWR?

02.

 

03.

SQL*Plus: Release 10.2.0.4.0 - Production on 11 26 01:02:30 2011

 

04.

 

05.

Copyright (c) 1982, 2007, Oracle. All Rights Reserved.

 

06.

 

07.

08.

:

09.

Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production

 

10.

With the Partitioning, OLAP, Data Mining and Real Application Testing options

11.

12.

13.

Current Instance

 

14.

~~~~~~~~~~~~~~~~

15.

 

16.

DB Id

DB Id

DB Name

Inst Num Inst Num Instance

 

17.

----------- ----------- ------------ -------- -------- ------------

18.

1293815896 1293815896 ORCL

 

1

1 orcl

19.

 

20.

21.

Specify the Report Type

 

22.

~~~~~~~~~~~~~~~~~~~~~~~

23.

Would you like an HTML report, or a plain text report?

 

24.

Enter 'html' for an HTML report, or 'text' for plain text

 

25.

Defaults to 'html'

 

26.

report_type : --html?

 

27.

 

28.

Type Specified: html

 

29.

 

30.

31.

Instances in this Workload Repository schema

 

32.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

33.

 

34.

DB Id

Inst Num DB Name

Instance

Host

35.

------------ -------- ------------ ------------ ------------

 

36.

* 1293815896

1 ORCL

orcl

linux

37.

 

38.

Database Id and Instance Number for the First Pair of Snapshots

 

39.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

40.

Using 1293815896 for Database Id for the first pair of snapshots

http://www.databaseskill.com/1718323/

26/09/2015

AWR (Automatic Workload Repository) - comparative report generator (2)! - Data

Página 2 de 3

41.

Using

1 for Instance Number for the first pair of snapshots

42.

 

43.

44.

Specify the number of days of snapshots to choose from

 

45.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

46.

Entering the number of days (n) will result in the most recent

47.

(n)

days of snapshots being listed. Pressing <return> without

48.

specifying a number lists all completed snapshots.

 

49.

 

50.

51.

num_days :

2

--2?

52.

 

53.

Listing the last 2 days of Completed Snapshots

 

54.

 

55.

 

Snap

56.

Instance

DB Name

 

Snap Id

Snap Started

Level

57.

------------ ------------ --------- ------------------ -----

58.

orcl

ORCL

 

90 25 11 2011 02:17

1

59.

 

91 25 11 2011 03:00

1

60.

92 25 11 2011 04:00

1

61.

93 25 11 2011 05:00

1

62.

94 25 11 2011 06:00

1

63.

95 25 11 2011 07:00

1

64.

96 25 11 2011 08:00

1

65.

 

66.

 

97 25 11 2011 23:59

1

67.

98

26 11 2011 01:00

1

68.

 

69.

70.

71.

Specify the First Pair of Begin and End Snapshot Ids

 

72.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

73.

begin_snap : 91

 

74.

First Begin Snapshot Id specified: 91 --?

 

75.

 

76.

end_snap :

92

 

77.

First End Snapshot Id specified: 92

--?

78.

 

79.

80.

81.

82.

Instances in this Workload Repository schema

 

83.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

84.

 

85.

DB Id

Inst Num DB Name

Instance

Host

86.

------------ -------- ------------ ------------ ------------

87.

* 1293815896

 

1 ORCL

orcl

linux

88.

 

89.

90.

91.

92.

Database Id and Instance Number for the Second Pair of Snapshots

93.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

94.

95.

Using 1293815896 for Database Id for the second pair of snapshots

96.

Using

1 for Instance Number for the second pair of snapshots

97.

 

98.

99.

Specify the number of days of snapshots to choose from

 

100.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

101.

Entering the number of days (n) will result in the most recent

102.

(n)

days of snapshots being listed. Pressing <return> without

103.

specifying a number lists all completed snapshots.

 

104.

 

105.

num_days2 :

2

--2?

106.

 

107.

Listing the last 2 days of Completed Snapshots

 

108.

 

109.

 

Snap

110.

Instance

DB Name

 

Snap Id

Snap Started

Level

111.

------------ ------------ --------- ------------------ -----

112.

orcl

ORCL

 

90 25 11 2011 02:17

1

113.

 

91 25 11 2011 03:00

1

114.

92 25 11 2011 04:00

1

115.

93 25 11 2011 05:00

1

116.

94 25 11 2011 06:00

1

117.

95 25 11 2011 07:00

1

118.

96 25 11 2011 08:00

1

119.

 

120.

 

97 25 11 2011 23:59

1

121.

98 26 11 2011 01:00

1

122.

 

123.

124.

125.

Specify the Second Pair of Begin and End Snapshot Ids

 

126.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

127.

begin_snap2 : 92

--?

http://www.databaseskill.com/1718323/

26/09/2015

AWR (Automatic Workload Repository) - comparative report generator (2)! - Data

Página 3 de 3

128.

Second Begin Snapshot Id specified: 92

129.

130.

end_snap2 :

93

--?

131.

Second End Snapshot Id specified: 93

132.

133.

134.

135.

Specify the Report Name

 

136.

~~~~~~~~~~~~~~~~~~~~~~~

137.

The default report file name is awrdiff_1_91_1_92.html To use this name,

138.

press <return> to continue, otherwise enter an alternative.

139.

140.

report_name : --?

 

141.

 

142.

Using the report name awrdiff_1_91_1_92.html

143.

144.

145.

146.

147.

148.

P>

149.

<P>

150.

<P>

151.

<P>

152.

<P>

153.

</BODY></HTML>

154.

Report written to awrdiff_1_91_1_92.html

http://www.databaseskill.com/1718323/

26/09/2015

AWR (Automatic Workload Repository) - Overview (1)! - Database - Database Skill

Página 1 de 2

AWR (Automatic Workload Repository) - Overview (1)!

Tag: Session, report, html, Performance report

Category: Database

Author: s12248326

Date: 2011-03-04

Category : Database Author : s12248326 Date : 2011-03-04 1) the AWR sampling interval and information

1) the AWR sampling interval and information retention information can query through the following view:

01.

SQL> select * from dba_hist_wr_control;

 

02.

03.

DBID SNAP_INTERVAL

RETENTION

TOPNSQL

04.

---------- -------------------- -------------------- ----------

05.

1293815896 +00000 01:00:00.0

+00007 00:00:00.0

DEFAULT

2) the AWR's behavior by the database is an important parameter:

01.

SQL> show parameter statistics_level

02.

03.

NAME

TYPE

VALUE

04.

------------------------------------ ----------- ------------------------------

05.

statistics_level

string

TYPICAL

Basic: AWR's statistics collection, and all the characteristics of self-adjustment are turned off.

Typical: database to collect some statistics, the default value.

ALL: All statistics are collected.

3) the AWR information recorded in the wrh $ _active_session_history partition table, view dba_hist_active_sess_history and to see.

Briefly summarize:

v $ session on behalf of the beginning of the database activity, as originated;

The v $ session_wait view to wait for the real-time recording activity session, current information;

The v $ SESSION_WAIT_HISTORY enhanced is v $ session_wait the simple activation activity session last 10 wait;

The v $ active_session_history ASH core of history to wait for information to record the activity session, one sample per second, this part is recorded in the memory, expectations record an hour;

wrh $ _active_session_history v $ active_session_history the AWR storage pool v $ ACTIVE_SESSION_HISTORY record information will be refreshed regularly (once per hour) to load the library, and the default one week reserved for the analysis of;

The view dba_hist_active_sess_history joint show wrh $ _active_session_history view and several other view historical data access, usually through this view.

Other:

The SYSAUX tablespace new in Oracle 10g AWR information storage ground.

awrrpti.sql AWR report on the production database or instance. This script is useful for the RAC database, direct connection on an instance can be generated for all instances of AWR performance reports. the awrextr.sql script for export AWR information, awrload.sql script for AWR data loaded. The data can be loaded by awrrpti.sql to the production report.

For example, the production database sample data import test libraries, you can compare the performance difference between the change in two or more persons.

Note: The sampling information export / import this process there is a problem in 10.2.0.4 and 10.2.0.5, the import is very slow!

AWR report generation:

01.

[oracle@linux db_1]$ sqlplus / as sysdba @?/rdbms/admin/awrrpt.sql

02.

03.

SQL*Plus: Release 10.2.0.4.0 - Production on 11 4 10:46:22 2011

04.

05.

Copyright (c) 1982, 2007, Oracle. All Rights Reserved.

06.

07.

08.

:

09.

Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production

http://www.databaseskill.com/1718405/

26/09/2015

AWR (Automatic Workload Repository) - Overview (1)! - Database - Database Skill

Página 2 de 2

10.

With the Partitioning, OLAP, Data Mining and Real Application Testing options

11.

12.

13.

Current Instance

 

14.

~~~~~~~~~~~~~~~~

15.

 

16.

DB Id

DB Name

Inst Num Instance

 

17.

----------- ------------ -------- ------------

 

18.

1290103567 ORCL

 

1 orcl

19.

 

20.

21.

Specify the Report Type

 

22.

~~~~~~~~~~~~~~~~~~~~~~~

23.

Would you like an HTML report, or a plain text report?

 

24.

Enter 'html' for an HTML report, or 'text' for plain text

25.

Defaults to 'html'

 

26.

report_type : html

--htmlawr?

 

27.

 

28.

Type Specified: html

 

29.

 

30.

31.

Instances in this Workload Repository schema

 

32.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

33.

 

34.

DB Id

Inst Num DB Name

Instance

Host

35.

------------ -------- ------------ ------------ ------------

36.

* 1290103567

1 ORCL

orcl

linux

37.

 

38.

Using 1290103567 for database Id

 

39.

Using

1 for instance number

 

40.

 

41.

42.

Specify the number of days of snapshots to choose from

 

43.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

44.

Entering the number of days (n) will result in the most recent

45.

(n) days of snapshots being listed. Pressing <return> without

46.

specifying a number lists all completed snapshots.

 

47.

 

48.

49.

num_days :

1

--1?

50.

 

51.

Listing the last day's Completed Snapshots

 

52.

 

53.

 

Snap

54.

Instance

DB Name

Snap Id

Snap Started

Level

55.

------------ ------------ --------- ------------------ -----

56.

orcl

ORCL

13 07 10 2011 12:07

1

57.

 

14 07 10 2011 13:00

1

58.

15 07 10 2011 14:01

1

59.

16 07 10 2011 15:00

1

60.

17 07 10 2011 16:00

1

61.

18 07 10 2011 17:00

1

62.

 

63.

64.

65.

Specify the Begin and End Snapshot Ids

 

66.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

67.

begin_snap :

17

 

68.

Begin Snapshot Id specified: 17

--17?

69.

 

70.

end_snap :

18

71.

End Snapshot Id specified: 18

--18?

72.

 

73.

74.

75.

Specify the Report Name

 

76.

~~~~~~~~~~~~~~~~~~~~~~~

77.

The default report file name is awrrpt_1_17_18.html. To use this name,

78.

press <return> to continue, otherwise enter an alternative.

79.

80.

report_name : /u01/app/oracle/awr.html

--awr?

81.

 

82.

using

83.

84.

85.

86.

Report written to /u01/app/oracle/awrr.html

 

http://www.databaseskill.com/1718405/

26/09/2015

The The AWR (Automatic Workload Repository) - (3)! - Database - Database Skill

Página 1 de 8

The The AWR (Automatic Workload Repository) - (3)!

Tag: buffer, cache, integer, the sql

Category: Database

Author: libin37

Date: 2011-03-04

sql Category : Database Author : libin37 Date : 2011-03-04 AWR a report in HTML format,
AWR a report in HTML format, for example: DB Name DB Id Instance Inst num
AWR a report in HTML format, for example:
DB Name
DB Id
Instance
Inst num
Release
RAC
Host
ORCL
1290103567 orcl
1 10.2.0.4.0
NO
linux
Snap Id
Sessions
Cursors / Session
Begin Snap:
17
22
2.6
End Snap:
18
22
2.6
Elapsed:
DB Time:
Snap Time
07-10 -11 16:00:10
07-10 -11 17:00:14
60.06 (mins)
0.05 (mins)

Sessions: collection instance to connect the number of sessions, this number can let us know about the circumstances of the number of concurrent users of the database, this value for us to determine the type of database.

Cursors / Session: Each session average number of open cursors.

DB Time: This value is more important, which means that it calls the user operation time, including CPU time and wait for an event. Pay attention to it refers to the time of the operation, and does not include the time spent by the database background process. We can see from the above list, the 60-minute period were occupied by the user's time of 0.05 seconds, the database is very busy (because it is only my test database). If this value is much greater than 60 minutes (because it is based on the cumulative record), indicating that the database is busy, then it should TOP5 waiting for an event to view exactly what events take up so much time in the system.

Cache Sizes Begin End Buffer Cache: 48M 48M Std Block Size: 8K Shared Pool Size:
Cache Sizes
Begin
End
Buffer Cache:
48M
48M Std Block Size:
8K
Shared Pool Size:
92M
92M Log Buffer:
2,856 K

This list shows the the AWR in performance capture start and end time, the size of the data buffer pool (Buffer Cache) and shared pool (Shared Pool Size). Can understand before and after the change of decency memory consumption.

Load Profile Per Second Per Transaction Redo size: 638.10 7,417.77 Logical reads: 6.96 80.90 Block
Load Profile
Per Second
Per Transaction
Redo size:
638.10
7,417.77
Logical reads:
6.96
80.90
Block changes:
2.20
25.55
Physical reads:
0.02
0.19
Physical writes:
0.26
2.99
User calls:
0.05
0.62
Parses:
0.76
8.83
Hard parses:
0.00
0.01
Sorts:
0.51
5.95
Logons:
0.02
0.21
Executes:
1.61
18.72
Transactions:
0.09
% Blocks changed per Read:
31.58 Recursive Call%:
99.44
Rollback per transaction%:
0.00 Rows per Sort:
9.12

These two parts is a database resource load DETAIL list is divided into the second resource load and resource load for each transaction, the performance indicators have the following meaning:

Redo size: per second (each transaction) the amount of redo generated. The unit is bytes, from above can know the database generated per second about 638/1024 = 0.6 kb redo, each transaction resulted in an average of about 7417/1024 = 7.2KB redo information. Logical reads: generated logical reads per second (each transaction) (corresponding to the physical read) Block changes: per second (each transaction) change the number of data blocks Physical Reads: per second (each transaction) physical read Physical Writes: per second (each transaction) physical write User calls: per second (each transaction) the number of calls of the user Parses: per second (each transaction) the number of analyzes Hard parses: per second (each transaction) the number of hard analysis Sorts: per second (each transaction) Sort frequency The number of logons: per second (each transaction) to log on to the database Executes: per second (each transaction) SQL execution times

http://www.databaseskill.com/1718257/

26/09/2015

The The AWR (Automatic Workload Repository) - (3)! - Database - Database Skill

Página 2 de 8

Transactions: per second (each transaction) number of transactions per second

Instance Efficiency Percentages (Target 100%)

In Buffer Nowait%: 100.00 Redo NOWAIT%: 100.00 Buffer Hit%: 99.77 In-memory Sort%: 100.00 Library Hit%:
In Buffer Nowait%:
100.00 Redo NOWAIT%:
100.00
Buffer Hit%:
99.77 In-memory Sort%:
100.00
Library Hit%:
99.89 Soft Parse%:
99.89
Execute to Parse%:
52.83 Latch Hit%:
100.00
Parse CPU to Parse Elapsd%:
14.55 % Non-Parse CPU:
90.85

For OLTP system, its significance is relatively significant, these values ??should be as close to 100%; OLAP systems the value of the level of the system seems little effect.

Buffer Nowait: Non wait to obtain the percentage of data blocks Redo NOWAIT:-wait access to redo the percentage of data Buffer Hit%: memory data block hit rate In-memory Sort%: the data block in the percentage of memory sort Library Hit%: shared pool sql resolve the hit rate Soft Parse%: soft analysis in the percentage of the total number of analysis Execute to Parse%: the number of executions on a percentage of the number of analyzes Latch Hit%: latch hit percentage Parse CPU to Parse Elapsd%: parsing the percentage of the total time consumed CPU time % Non-Parse CPU: CPU analysis time in the percentage of CPU time

Top 5 Timed Events

Time AVG Wait % Total Call Wait Event Waits (s) (ms) Time Class control file
Time
AVG Wait
% Total Call
Wait
Event
Waits
(s)
(ms)
Time
Class
control file parallel
write
CPU time
log file parallel
write
System I /
1,197
8
6
279.9
O
2
64.0
System I /
382
2
4
61.7
O
System I /
db file parallel write
573
1
2
50.2
O
control file
System I /
3,019
1
0
27.4
sequential
read
O
RAC Statistics
Begin End Number of Instances: 2 2 Global Cache Load Profile
Begin
End
Number of Instances:
2
2
Global Cache Load Profile

This section is the most important part of the AWR report, a wait event in the share of the acquisition cycle of an hour too long, you need to focus on. If this part of the top 5 wait events total did not long to wait, then I think this AWR report there is no need to imagine what will happen, the state of the system because it looks very good - almost too long to wait for the operator, so I do not needs to be done to optimize performance. Note: This Waits said the number of waiting!

Per Second Per Transaction Global Cache blocks received: 8.31 0.58 Global Cache blocks served: 4.12
Per Second
Per Transaction
Global Cache blocks received:
8.31
0.58
Global Cache blocks served:
4.12
0.29
GCS / GES messages received:
27.19
1.89
GCS / GES messages sent:
36.65
2.55
DBWR Fusion writes:
0.39
0.03
Estd Interconnect traffic (KB)
111.88

Global Cache Efficiency Percentages (Target local + remote 100%)

Buffer access - local cache%: 96.55 Buffer access - remote cache%: 0.81 Buffer access -
Buffer access - local cache%:
96.55
Buffer access - remote cache%:
0.81
Buffer access - disk%:
2.63
Global Cache and Enqueue Services - Workload Characteristics
Avg global enqueue get time (ms):
0.0
Avg global cache cr block receive time (ms):
0.4
Avg global cache current block receive time (ms):
0.5
Avg global cache cr block build time (ms):
0.0
Avg global cache cr block send time (ms):
0.0
Global cache log flushes for cr blocks served%:
0.1
Avg global cache cr block flush time (ms):
0.0
Avg global cache current block pin time (ms):
0.0
Avg global cache current block send time (ms):
0.0
Global cache log flushes for current blocks served%:
0.0
Avg global cache current block flush time (ms):

http://www.databaseskill.com/1718257/

26/09/2015

The The AWR (Automatic Workload Repository) - (3)! - Database - Database Skill

Página 3 de 8

Global Cache and Enqueue Services - Messaging Statistics

0.0 0.2 0.0 0.0 0.0 29.88 23.50 46.62
0.0
0.2
0.0
0.0
0.0
29.88
23.50
46.62
Avg message sent queue time (ms): Avg message sent queue time on ksxp (ms): Avg
Avg message sent queue time (ms):
Avg message sent queue time on ksxp (ms):
Avg message received queue time (ms):
Avg GCS message process time (ms):
Avg GES message process time (ms):
% Of direct sent messages:
% Of indirect sent messages:
% Of flow controlled messages:
Time Model Statistics
Statistic Name
sql execute elapsed time
DB CPU
parse time elapsed
hard parse elapsed time
PL / SQL execution elapsed time
PL / SQL compilation elapsed time
connection management call elapsed time
hard parse (sharing criteria) elapsed time
repeated bind elapsed time
hard parse (bind mismatch) elapsed time
sequence load elapsed time
DB time
background elapsed time
background cpu time
Time (s) % Of DB Time
9.42
88.00
7.66
71.60
2.86
26.68
2.43
22.67
1.65
15.39
0.43
3.98
0.22
2.07
0.03
0.31
0.01
0.10
0.01
0.08
0.00
0.01
10.70
22.99
9.88

This section only to appear in a RAC environment, global memory data transmission, the receiver performance indicators, there are some global lock information, unless the database is running normal when setting a baseline as a reference, otherwise part of the performance index value is difficult to say whether there is a performance problem.

Total time in database user-calls (DB Time): 10.7s Statistics including the word "background" measure background process time, and so do not contribute to the DB time statistic Ordered by% or DB time desc, Statistic name

This part of the information listed in the proportion of time occupied database of the various operations, but also very useful part.

Wait Class

s - second cs - centisecond - 100th of a second ms - millisecond - 1000th of a second us - microsecond - 1000000th of a second ordered by wait time desc, waits desc

Wait Class System I / O User I / O Waits % Time-outs Total Wait
Wait Class
System I / O
User I / O
Waits % Time-outs Total Wait Time (s) Avg wait (ms) Waits / txn
5,986
0.00
12
2
10.01
349
0.00
4
10
0.58
Commit
260
0.00
2
6
0.43
Concurrency
5
0.00
0
37
0.01
Application
302
0.00
0
1
0.51
Other
49
0.00
0
1
0.08
Network
6,981
0.00
0
0
11.67
Configuration
1
100.00
0
6
0.00
This part is waiting for the type of event which is waiting for an event, you can clearly see what type of.
SQL ordered by Elapsed Time
Resources reported for PL / SQL code includes the resources used by all SQL statements called by the code.
% Total DB Time is the Elapsed Time of the SQL statement divided into the Total Database Time multiplied by 100
Elapsed Time
CPU time
Executions Elap per Exec
% Total DB
SQL
SQL Module
SQL Text
(s)
(s)
(s)
Time
Id
2
1
60
0.03
14.89
1
1
2,154
0.00
13.44
OEM.SystemPool
DECLARE job BINARY_INTEGER: =
begin MGMT_JOB_ENGINE.get_sche
The CALL
0
0
41
0.01
4.34
The INSERT INTO MGMT_METRICS_RAW (C.
0
0
94
0.00
4.19
OEM.Loader
0
0
2
0.19
3.48
OEM.BoundedPool
begin setEMUserContext (: 1,: 2

http://www.databaseskill.com/1718257/

26/09/2015

The The AWR (Automatic Workload Repository) - (3)! - Database - Database Skill

Página 4 de 8

0 0 119 0.00 3.32 OEM.SystemPool 0 0 18 0.02 2.70 0 0 60 0.00
0
0
119
0.00
3.32
OEM.SystemPool
0
0
18
0.02
2.70
0
0
60
0.00
2.67
OEM.SystemPool
0
0
1,008
0.00
2.29
0
0
4
0.06
2.27
OEM.BoundedPool
0
0
9
0.02
1.69
OMS
0
0
2,217
0.00
1.44
0
0
1
0.15
1.42
0
0
2,154
0.00
1.42
OEM.SystemPool
0
0
181
0.00
1.35
0
0
17
0.01
1.32
OEM.Loader
0
0
719
0.00
1.25
0
0
96
0.00
1.21
The BEGIN EMD_NOTIFICATION.QUEUE_R
select obj #, dataobj #, part #
The BEGIN
EM_PING.RECORD_BATCH_HEA
update sys.col_usage $ set eq
INSERT INTO MGMT_SEVERITY
SELECT OWNER FROM DBA_PROCEDUR to
select / * + rule * / bucket_cnt,
insert into wrh $ _sga_target_ad
SELECT JOB_ID, EXECUTION_ID,
select i.obj #, i.ts #, i.file #,
The BEGIN
EMD_LOADER.UPDATE_LOADER
select job, nvl2 (last_date,
select / * + index (idl_ub1 $ i_id
emagent @ linux (TNS V1-
0
0
12
0.01
1.14
/ * OracleOEM * / DECLARE l_l
V3)
0
0
145
0.00
1.14
0
0
1,333
0.00
1.12
OEM.Loader
0
0
1
0.11
1.06
0
0
5
0.02
1.05
OEM.BoundedPool
0
0
422
0.00
1.03
0
0
96
0.00
1.00
select order #, columns, types
The UPDATE MGMT_CURRENT_METRICS
SE
insert into wrh $ _pgastat
The BEGIN EMD_LOADER.obtain_lock_f
select obj #, type #, ctime, mti
select / * + index (idl_ub2 $ i_id
Sql execution time from long to short sort.
Elapsed Time (s): SQL execution total time
CPU Time (s): sql execution consume cpu time
Executions: SQL execution times
Elap per Exec (s): SQL 'each execution time consumed
% Total DB Time: SQL execution time of the total of the percentage in DB Time
SQL ordered by CPU Time
Resources reported for PL / SQL code includes the resources used by all SQL statements called by the code.
% Total DB Time is the Elapsed Time of the SQL statement divided into the Total Database Time multiplied by 100
CPU time
Elapsed Time
% Total DB
SQL
Executions CPU per Exec
SQL Module
SQL Text
(s)
(s)
(s)
Time
Id
1
1
2,154
0.00
13.44
OEM.SystemPool
1
2
60
0.02
14.89
0
0
119
0.00
3.32
OEM.SystemPool
begin MGMT_JOB_ENGINE.get_sche
DECLARE job BINARY_INTEGER: =
The BEGIN EMD_NOTIFICATION.QUEUE_R
The INSERT INTO MGMT_METRICS_RAW (C.
0
0
94
0.00
4.19
OEM.Loader
The CALL
0
0
41
0.01
4.34
0
0
60
0.00
2.67
OEM.SystemPool
0
0
1,008
0.00
2.29
0
0
1
0.15
1.42
0
0
2,154
0.00
1.42
OEM.SystemPool
0
0
2
0.07
3.48
OEM.BoundedPool
0
0
4
0.04
2.27
OEM.BoundedPool
0
0
719
0.00
1.25
0
0
2,217
0.00
1.44
The BEGIN
EM_PING.RECORD_BATCH_HEA
update sys.col_usage $ set eq
insert into wrh $ _sga_target_ad
SELECT JOB_ID, EXECUTION_ID,
begin setEMUserContext (: 1,: 2
INSERT INTO MGMT_SEVERITY
select job, nvl2 (last_date,
select / * + rule * / bucket_cnt,
emagent @ linux (TNS V1-
0
0
12
0.01
1.14
/ * OracleOEM * / DECLARE l_l
V3)
0
0
1,333
0.00
1.12
OEM.Loader
0
0
18
0.01
2.70
0
0
181
0.00
1.35
0
0
422
0.00
1.03
0
0
9
0.01
1.69
OMS
0
0
96
0.00
1.21
0
0
17
0.00
1.32
OEM.Loader
0
0
145
0.00
1.14
0
0
5
0.01
1.05
OEM.BoundedPool
0
0
96
0.00
1.00
0
0
1
0.02
1.06
The UPDATE MGMT_CURRENT_METRICS
SE
select obj #, dataobj #, part #
select i.obj #, i.ts #, i.file #,
select obj #, type #, ctime, mti
SELECT OWNER FROM DBA_PROCEDUR to
select / * + index (idl_ub1 $ i_id
The BEGIN
EMD_LOADER.UPDATE_LOADER
select order #, columns, types
The BEGIN EMD_LOADER.obtain_lock_f
select / * + index (idl_ub2 $ i_id
insert into wrh $ _pgastat

sql cpu time consumed in descending sort.

http://www.databaseskill.com/1718257/

26/09/2015

The The AWR (Automatic Workload Repository) - (3)! - Database - Database Skill

Página 5 de 8

CPU Time (s): SQL consumed cpu time

Elapsed Time (s): sql execution time

Executions: SQL execution times

CPU per Exec (s): consumption of CPU time each execution

% Total DB Time: SQL execution time of the total of the percentage in DB Time

SQL ordered by Gets

Resources reported for PL / SQL code includes the resources used by all SQL statements
Resources reported for PL / SQL code includes the resources used by all SQL statements called by the code.
Total Buffer Gets: 95,886
Captured SQL account for 64.7% of Total
Buffer
Gets per
%
CPU time
Elapsed Time
SQL
Executions
SQL Module
SQL Text
Gets
Exec
Total
(s)
(s)
Id
15,745
60
262.42
16.42
1.18
1.59
12,924
2,154
6.00
13.48
1.41
1.44
OEM.SystemPool
7,036
94
74.85
7.34
0.34
0.45
OEM.Loader
6,462
2,154
3.00
6.74
0.15
0.15
OEM.SystemPool
5,850
2,217
2.64
6.10
0.13
0.15
4,228
1,333
3.17
4.41
0.12
0.12
OEM.Loader
DECLARE job BINARY_INTEGER: =
begin MGMT_JOB_ENGINE.get_sche
The INSERT INTO MGMT_METRICS_RAW
SELECT JOB_ID, EXECUTION_ID,
select / * + rule * / bucket_cnt,
The UPDATE MGMT_CURRENT_METRICS SE
The CALL
3,738
41
91.17
3.90
0.31
0.46
3,332
119
28.00
3.47
0.36
0.36
OEM.SystemPool
3,304
60
55.07
3.45
0.24
0.29
OEM.SystemPool
The BEGIN EMD_NOTIFICATION.QUEUE_R
The BEGIN EM_PING.RECORD_BATCH_HEA
3,293
1,008
3.27
3.43
0.24
0.24
2,451
4
612.75
2.56
0.15
0.24
2,152
213
10.10
2.24
0.05
0.05
1,849
145
12.75
1.93
0.05
0.08
update sys.col_usage $ set eq
OEM.BoundedPool INSERT INTO MGMT_SEVERITY
select privilege #, level from
select owner #, name, namespace
1,542
181
8.52
1.61
0.06
0.14
1,501
719
2.09
1.57
0.13
0.13
1,283
145
8.85
1.34
0.05
0.12
1,242
422
2.94
1.30
0.06
0.11
1,193
60
19.88
1.24
0.04
0.04
1,119
2
559.50
1.17
0.15
0.37
select i.obj #, i.ts #, i.file #,
select job, nvl2 (last_date,
select order #, columns, types
select obj #, type #, ctime, mti
SELECT C.TARGET_GUID, C.METRI
OEM.BoundedPool begin setEMUserContext (: 1,: 2
1,099
152
7.23
1.15
0.04
0.04
OEM.Loader
1,072
134
8.00
1.12
0.04
0.08
OEM.Loader
981
9
109.00
1.02
0.06
0.18
OMS
The INSERT INTO MGMT_SYSTEM_PERFOR
SELECT INSTANTIABLE, supertyp
SELECT OWNER FROM DBA_PROCEDUR to

SQL access to the memory number of data blocks, sorted in descending order.

Buffer Gets: the sql perform memory number of data blocks

Executions: SQL execution times

Gets per Exec: each time you run the memory number of data blocks

% Total: accounting for the percentage of the total number of

CPU Time (s): cpu time consumption

Elapsed Time (s): sql execution time

SQL ordered by Reads

Total Disk Reads: 328 Captured SQL account for 89.3% of Total Physical Reads per %
Total Disk Reads: 328
Captured SQL account for 89.3% of Total
Physical
Reads per
%
CPU time
Elapsed Time
SQL
Executions
SQL Module
SQL Text
Reads
Exec
Total
(s)
(s)
Id
97
60
1.62
29.57
1.18
1.59
DECLARE job BINARY_INTEGER: =
The CALL
86
41
2.10
26.22
0.31
0.46
82
9
9.11
25.00
0.06
0.18
OMS
19
18
1.06
5.79
0.10
0.29
16
4
4.00
4.88
0.15
0.24
OEM.BoundedPool
14
2
7.00
4.27
0.15
0.37
OEM.BoundedPool
10
145
0.07
3.05
0.05
0.12
10
17
0.59
3.05
0.05
0.14
OEM.Loader
9
96
0.09
2.74
0.03
0.11
9
5
1.80
2.74
0.04
0.11
OEM.BoundedPool
9
96
0.09
2.74
0.06
0.13
9
96
0.09
2.74
0.04
0.10
SELECT OWNER FROM DBA_PROCEDUR
to
select obj #, dataobj #, part #
INSERT INTO MGMT_SEVERITY
begin setEMUserContext (: 1,: 2
select order #, columns, types
The BEGIN
EMD_LOADER.UPDATE_LOADER
select / * + index (idl_ub2 $ i_id
The BEGIN EMD_LOADER.obtain_lock_f
select / * + index (idl_ub1 $ i_id
select / * + index (idl_sb4 $ i_id

http://www.databaseskill.com/1718257/

26/09/2015

The The AWR (Automatic Workload Repository) - (3)! - Database - Database Skill

Página 6 de 8

7 96 0.07 2.13 0.04 0.09 6 422 0.01 1.83 0.06 0.11 select / *
7
96
0.07
2.13
0.04
0.09
6
422
0.01
1.83
0.06
0.11
select / * + index (idl_char $ i_i
select obj #, type #, ctime, mti
The INSERT INTO MGMT_METRICS_RAW (C.
5
94
0.05
1.52
0.34
0.45
OEM.Loader
5
6
0.83
1.52
0.02
0.06
OEM.Loader
5
145
0.03
1.52
0.05
0.08
The INSERT INTO
MGMT_STRING_METRIC
select owner #, name, namespace
emagent @ linux (TNS V1-
4
12
0.33
1.22
0.05
0.10
/ * OracleOEM * / BEGIN IF (:
V3)
4
181
0.02
1.22
0.06
0.14
4
2,217
0.00
1.22
0.13
0.15
select i.obj #, i.ts #, i.file #,
select / * + rule * / bucket_cnt,
This section lists the SQL to perform a physical read, in descending order.

Physical Reads: sql physical number of Reading

Executions: SQL execution times

Reads per Exec: sql each time you perform physical read

% Total: accounting for the percentage of the entire physical read

CPU Time (s): sql execution consumed cpu time

Elapsed Time (s): SQL execution time

SQL ordered by Executions

Total Executions: 24,941 Captured SQL account for 67.4% of Total

Rows Rows per CPU per Exec Elap per Exec SQL Executions SQL Module SQL Text
Rows
Rows per
CPU per Exec
Elap per Exec
SQL
Executions
SQL Module
SQL Text
Processed
Exec
(s)
(s)
Id
2,217
1,416
0.64
0.00
0.00
2,214
2,214
1.00
0.00
0.00
EM_PING
select / * + rule * / bucket_cnt,
SELECT SYS_EXTRACT_UTC
2,154
0
0.00
0.00
0.00
OEM.SystemPool SELECT JOB_ID, EXECUTION_ID,
2,154
2,154
1.00
0.00
0.00
OEM.SystemPool begin MGMT_JOB_ENGINE.get_sche
The UPDATE MGMT_CURRENT_METRICS
1,333
1,333
1.00
0.00
0.00
OEM.Loader
1,008
881
0.87
0.00
0.00
719
60
0.08
0.00
0.00
422
398
0.94
0.00
0.00
364
0
0.00
0.00
0.00
289
289
1.00
0.00
0.00
SE
update sys.col_usage $ set eq
select job, nvl2 (last_date,
select obj #, type #, ctime, mti
the lock table sys.col_usage $ in e
select type #, blocks, extents,

This section lists the SQL execution times, installed in descending order sorting.

Executions: SQL execution times

Rows Processed: sql number of records processed

Rows per Exec: each time you perform a number of records processed

CPU per Exec (s): each time you run the consumption of CPU time

Elap per Exec (s): each execution time

SQL ordered by Parse Calls

Total Parse Calls: 7,909 Captured SQL account for 56.8% of Total Parse Calls Executions %
Total Parse Calls: 7,909
Captured SQL account for 56.8% of Total
Parse Calls Executions % Total Parses SQL Id
SQL Module
364
127
4.60
364
1,008
4.60
364
364
4.60
289
289
3.65
213
213
2.69
185
185
2.34
172
172
2.17
172
172
2.17
145
145
1.83
145
145
1.83
134
134
1.69
OEM.Loader
SQL Text
insert into sys.col_usage $
update sys.col_usage $ set eq
the lock table sys.col_usage $ in e
select type #, blocks, extents,
select privilege #, level from
select timestamp, flags from
lock table sys.mon_mods $ in ex
update sys.mon_mods $ set inser
select order #, columns, types
select owner #, name, namespace
SELECT INSTANTIABLE, supertyp
119
119
1.50
112
172
1.42
96
96
1.21
OEM.SystemPool The BEGIN EMD_NOTIFICATION.QUEUE_R
SELECT COUNT (*) FROM MGMT_PARA
select / * + index (idl_ub2 $ i_id

http://www.databaseskill.com/1718257/

26/09/2015

The The AWR (Automatic Workload Repository) - (3)! - Database - Database Skill

Página 7 de 8

96 96 1.21 96 96 1.21 96 96 1.21 85 85 1.07 select / *
96
96
1.21
96
96
1.21
96
96
1.21
85
85
1.07
select / * + index (idl_char $ i_i
select / * + index (idl_ub1 $ i_id
select / * + index (idl_sb4 $ i_id
select privilege # from sysauth
This section lists the sql analysis, in accordance with the high in the end.

Parse Calls: the sql analysis of the number of times

Executions: sql number of executions

% Total Parses: accounting for the overall analysis of the percentage of times

SQL ordered by Version Count

Only Statements with Version Count greater than 20 are displayed

Version Count Executions SQL Id SQL Module SQL Text 42 819 select / * +
Version Count
Executions SQL Id SQL Module
SQL Text
42
819
select / * + rule * / bucket, end
27
823
select o.owner #, o.name, o.nam
25
202
select i.obj #, i.ts #, i.file #,

This section lists the SQL multi-version information.

Version count: the number of the version of SQL

Executions: SQL execution times

SQL ordered by Cluster Wait Time

Cluster Wait CWT% of Elapsed CPU (s) Executions SQL SQL Module SQL Text Time (s)
Cluster Wait
CWT% of
Elapsed
CPU
(s) Executions SQL
SQL Module
SQL Text
Time (s)
Elapsd Time
Time (s)
time
Id
1.61
28.98
5.55
4.23
85
serv_proc @
zfyw_payoln (TNS V1-
SELECT * FROM (SELECT T1.MERNO
V3)
1.18
3.86
30.45
28.35
180
JDBC Thin Client
serv_proc @
zfyw_payoln (TNS V1-
select ID, DESTNO, LIVETIME,
1.15
65.96
1.74
0.71
890
The INSERT INTO T_PAY_ORDER_INFO
V3)
0.70
75.76
0.93
0.30
890
serv_proc @
zfyw_payoln (TNS V1-
select count (t.id) +1, to_char (
V3)
0.69
1.72
40.04
2.79
1
PL / SQL Developer
- 3.2 the number of active users daily report SQL - can not be
divided into independent registered or Wal
0.63
46.16
1.37
0.38
966
serv_proc @
zfyw_payoln (TNS V1-
The INSERT INTO T_PAY_SYSTEM_JOURN
V3)
0.34
64.22
0.53
0.18
774
serv_proc @
zfyw_payoln (TNS V1-
As UPDATE T_PAY_SYSTEM_JOURNAL SE
V3)
0.23
18.63
1.23
0.20
1,880
insert into t_pay_merbindagr
0.23
74.21
0.30
0.09
890
JDBC Thin Client
serv_proc @
zfyw_payoln (TNS V1-
SELECT ID, to_char (amount), ST
V3)
0.20
3.08
6.43
0.15
1,880
0.19
43.74
0.43
0.10
935
JDBC Thin Client
serv_proc @
zfyw_payoln (TNS V1-
select agrno, status from t_pa
As UPDATE T_PAY_SYSTEM_JOURNAL SE
V3)
0.16
2.68
6.12
0.22
4,398
select * from (select t.usern
0.12
18.49
0.64
0.57
47
JDBC Thin Client
serv_proc @
zfyw_payoln (TNS V1-
UPDATE T_PAY_ORD_AUTO_NOTIFY,
V3)
0.11
9.62
1.11
0.06
966
serv_proc @
zfyw_payoln (TNS V1-
select t.agrno from T_PAY_MERB
V3)
0.10
3.19
3.21
2.55
1
0.08
13.09
0.64
0.09
1,882
0.08
7.62
1.06
0.18
19,140
0.08
1.88
4.17
0.13
4,176
plsqldev.exe
JDBC Thin Client
JDBC Thin Client
JDBC Thin Client
0.08
17.65
0.44
0.10
1,703
0.08
2.11
3.68
0.22
18,079
select s.synonym_name object_n
insert into T_PAY_USRMBLNO_BIN
SELECT: B1 | | '00 '| | LPAD (TO
select count (*) from t_pay_usr
update seq $ set increment $ =: 2,
select * from (the select f_gen_j
0.06
17.83
0.35
0.27
25
JDBC Thin Client
serv_proc @
zfyw_payoln (TNS V1-
UPDATE T_PAY_ORD_AUTO_NOTIFY,
V3)
0.06
16.78
0.34
0.03
1,889
0.02
1.36
1.27
0.00
2,270
0.01
2.14
0.66
0.02
4,542
JDBC Thin Client
JDBC Thin Client
JDBC Thin Client
0.01
5.44
0.21
0.05
819
insert into T_PAY_SMSEND t (ti
select userno from t_pay_useri
select t.STATUS, t.REGTYPE, t
select / * + rule * / bucket, end

http://www.databaseskill.com/1718257/

26/09/2015

The The AWR (Automatic Workload Repository) - (3)! - Database - Database Skill

Página 8 de 8

0.01 2.04 0.48 0.01 4,542 0.01 1.38 0.61 0.03 5,646 0.01 25.54 0.03 0.00 18
0.01
2.04
0.48
0.01
4,542
0.01
1.38
0.61
0.03
5,646
0.01
25.54
0.03
0.00
18
0.01
0.66
0.84
0.06
3,764
0.01
11.51
0.05
0.04
4
JDBC Thin Client
JDBC Thin Client
JDBC Thin Client
JDBC Thin Client
plsqldev.exe
0.01
3.24
0.16
0.14
1
0.01
1.31
0.40
0.01
1,933
0.01
9.83
0.05
0.02
132
JDBC Thin Client
plsqldev.exe
select t.MOBILENO from T_PAY_U
insert into T_PAY_USERSUBSCRIB
select * from (select rownum rn
insert into T_PAY_CUSTOMERPWDI
select null from all_synonyms
insert into wrh $ _latch
select * from (select count (*
select value (p $) from "XDB".

This part only in a RAC environment only, lists the instance of sharing data between the wait.

Cluster Wait Time (s): cluster wait long

CWT% of Elapsd Time: cluster operation waits long total duration of

Elapsed Time (s): sql execution total duration

CPU Time (s): sql execution consume cpu time

Executions: SQL execution times

http://www.databaseskill.com/1718257/

26/09/2015

The The AWR (Automatic Workload Repository) - (4)! - Database - Database Skill

Página 1 de 4

The The AWR (Automatic Workload Repository) - (4)!

Tag: buffer, cache, session, library

Category: Database

Author: jlh869

Date: 2011-01-10

Category : Database Author : jlh869 Date : 2011-01-10 Continued access front Instance Activity Stats Statistic

Continued access front

Instance Activity Stats

Statistic Total per Second per Trns CPU used by this session 99,100 102.31 91.84
Statistic
Total per Second per Trns
CPU used by this session 99,100
102.31
91.84

.

.

.

.

.

.

This is partly instance statistics, project very much, I value above focus on this event.

CPU used by this session: this indicator inside the current performance acquisition interval, Oracle consumption of CPU unit, a cpu unit is 1/100 second.

Suppose we now system 6 cpu server, and every single cpu consumption of CPU units is 102/6 = 17 cpu units.

In one second, each CPU processing time is 17/100 = 0.17 seconds. From here you can determine the database CPU resource-rich, far from being a bottleneck.

Tablespace IO Stats

 

ordered by IOs (Reads + Writes) desc

Tablespace Reads Av Reads / s AV Rd (ms) Av Blks / Rd Writes Av
Tablespace Reads Av Reads / s AV Rd (ms) Av Blks / Rd Writes Av Writes / s Buffer Waits AV BUF Wt (ms)
SYSAUX
227
0
9.96
1.01
420
0
0
0.00
UNDOTBS1
5
0
4.00
1.00
217
0
1
10.00
SYSTEM
120
0
11.67
1.75
74
0
0
0.00

This section is the table space I / O performance statistics, this data is relative.

Reads: the number of physical reads

Av Reads / s: the number of times per second physical reads

Av Rd (ms): The average time the physical reading time (in milliseconds)

Av Blks / Rd: each time the number of data blocks

Writes: the number of write

Av Writes / s: write the number of times per second

Buffer Waits: Get the number of memory data block waiting

AV BUF Wt (ms): The average waiting time for memory data block

File IO Stats

ordered by Tablespace, File Tablespace Filename / U01/app/oracle/oradata/orcl/sysaux01.dbf /
ordered by Tablespace, File
Tablespace
Filename
/ U01/app/oracle/oradata/orcl/sysaux01.dbf
/ U01/app/oracle/oradata/orcl/system01.dbf
Reads Av Reads / s AV Rd (ms)
Av Blks / Rd Writes Av Writes / s Buffer Waits AV BUF Wt (ms)
SYSAUX
227
0
9.96
1.01
420
0
0
0.00
SYSTEM
120
0
11.67
1.75
74
0
0
0.00
UNDOTBS1 / U01/app/oracle/oradata/orcl/undotbs01.dbf
5
0
4.00
1.00
217
0
1
10.00
Part of this is a file-level I / O statistics, and on the part of the table space information.

Starting from this part of the following, you will see the Oracle gives some suggestions on the size of the various memory components.

Parts does not help the group our the intuitive positioning system performance, but it gives us some recommendations on the size of the memory component of several Oracle, so we should look at here, in order to know the current database set is reasonable in this regard.

Buffer Pool Advisory

Only rows with estimated physical reads> 0 are displayed ordered by Block Size, Buffers For Estimate

http://www.databaseskill.com/1544008/

26/09/2015

The The AWR (Automatic Workload Repository) - (4)! - Database - Database Skill

Página 2 de 4

P Size for Est (M) Size Factor Buffers for Estimate Est Phys Read Factor Estimated
P Size for Est (M) Size Factor Buffers for Estimate Est Phys Read Factor Estimated Physical Reads
D
96
0.10
11,502
1.01
9,280,242,678
D
192
0.20
23,004
1.01
9,221,206,840
D
288
0.30
34,506
1.00
9,203,382,424
D
384
0.40
46,008
1.00
9,187,795,751
D
480
0.50
57,510
1.00
9,173,359,689
D
576
0.60
69,012
1.00
9,170,239,226
D
672
0.70
80,514
1.00
9,167,537,392
D
768
0.80
92,016
1.00
9,165,125,531
D
864
0.90
103,518
1.00
9,162,962,005
D
960
1.00
115,020
1.00
9,160,956,280
D
1,056
1.10
126,522
1.00
9,159,872,178
D
1,152
1.20
138,024
1.00
9,158,692,041
D
1,248
1.30
149,526
1.00
9,157,439,260
D
1,344
1.40
161,028
1.00
9,156,077,677
D
1,440
1.50
172,530
1.00
9,154,595,433
D
1,536
1.60
184,032
1.00
9,141,375,909
D
1,632
1.70
195,534
1.00
9,117,577,424
D
1,728
1.80
207,036
0.99
9,093,764,198
D
1,824
1.90
218,538
0.99
9,069,947,117
D
1,920
2.00
230,040
0.79
7,195,790,859

This part of the recommendations of the size of the buffer pool.

Size for Est (M): Oracle to estimate the size of the buffer pool

Size Factor: estimates and the actual value of a ratio, such as 0.9 estimates 90% of the size of the actual value of 1.0 indicates the actual size of the buffer pool

Buffers for Estimate: estimated buffer size (number)

Est Phys Read Factor: the impact factor of the estimated physical reads, is to estimate a ratio of physical reads and physical reads 1.0 represents the actual physical read

Estimated Physical Reads: The estimated number of physical reads now we see the actual buffer pool size is 960MB (Size Factor = 1.0), the number of physical reads issued 9,160,956,280 times, when Oracle attempts to increase the buffer pool to 1.1 times the size (Size Factor = 1.1), physical reads reduced to 9,159,872,178,

reduced physical read 9,160,956,280-9,159,872,178 = 1,084,102. If we continue to increase the size of the buffer pool to 2 times, reduce physical read 7,195,790,859 times, reducing the 9,160,956,280-7,195,790,859 = 1965165421. Although we will buffer the size of the pool doubled doubled the degree of decline in physical reads

is limited but the price we pay is very large. So we can not just by increasing the memory to reduce physical read, need to find one of the most economical, efficient

and high point, which is the purpose of the Oracle recommends. In fact, it can be seen from the above system is still very busy, the buffer pool is slightly larger and

smaller physical reads the impact will not be very large.

PGA Memory Advisory

When using Auto Memory Mgmt, minimally choose a pga_aggregate_target value where Estd PGA Overalloc Count is 0

PGA Target Est (MB) Size Factr W / A MB Processed Estd Extra W /
PGA Target Est (MB) Size Factr W / A MB Processed Estd Extra W / A MB Read / Written to Disk Estd PGA Cache Hit% Estd PGA Overalloc Count
610
0.13
548,398.44
284,625.95
66.00
303
1,220
0.25
548,398.44
275,104.64
67.00
286
2,440
0.50
548,398.44
263,712.09
68.00
176
3,659
0.75
548,398.44
229,058.85
71.00
142
4,879
1.00
548,398.44
27,379.49
95.00
0
5,855
1.20
548,398.44
25,113.76
96.00
0
6,831
1.40
548,398.44
25,113.76
96.00
0
7,806
1.60
548,398.44
25,113.76
96.00
0
8,782
1.80
548,398.44
25,113.76
96.00
0
9,758
2.00
548,398.44
25,113.76
96.00
0
14,637
3.00
548,398.44
25,113.76
96.00
0
19,516
4.00
548,398.44
25,113.76
96.00
0
29,274
6.00
548,398.44
25,113.76
96.00
0
39,032
8.00
548,398.44
25,113.76
96.00
0

Some of the recommendations is the proposal on the PGA memory size.

PGA Target Est (MB): the PGA estimates of the size of

Size Factr: impact factor, the role and the same buffer pool

W / A MB Processed: Oracle amount of data processing in order to produce estimates

The estd Extra W / A MB Read / written to the disk: processing of data need to be physically read and write the amount of data

Estd PGA Cache Hit%: estimated PGA hit rate

Estd PGA Overalloc Count: the number of additional memory allocated in the estimated size of the PGA this section we want to determine whether two points, the first point is the size of the Oracle Estimated PGA does not result in additional memory allocation in the table above Size Factor = 1.0 PGA size; the second point of the physical read and write the value does not increase, in the Size Factor = 1.2 when, if you want these two conditions are met, we need to take the Size Factor = 1.2 when the PGA size , 5855MB, that is, if you want to reach the PGA performance the best, should be pga_aggregate_target set to 5855MB, although this value is better than the previous value of the performance, but we need to consider the actual memory.

http://www.databaseskill.com/1544008/

26/09/2015

The The AWR (Automatic Workload Repository) - (4)! - Database - Database Skill

Página 3 de 4

Shared Pool Advisory

SP: Shared Pool Est LC: Estimated Library Cache Factr: Factor Note there is often a
SP: Shared Pool Est LC: Estimated Library Cache Factr: Factor
Note there is often a 1: Many correlation between a single logical object in the Library Cache, and the physical number of memory objects associated with it.
Therefore comparing the number of Lib Cache objects (eg in v $ librarycache), with the number of Lib Cache Memory Objects is invalid.
Shared Pool
SP Size
EST LC Size
Est LC Mem
Est LC Time
Est LC Time
Size (M)
factr is
(M)
Obj
Saved (s)
Saved Factr
Est LC Load
Time (s)
Est LC Load
Time Factr
Est LC Mem Obj
Hits (K)
320
0.63
69
7,243
2,390,521
1.00
8,187
1.34
343,271
384
0.75
131
13,655
2,391,420
1.00
7,288
1.19
343,453
448
0.88
193
19,589
2,392,063
1.00
6,645
1.08
343,577
512
1.00
256
26,030
2,392,577
1.00
6,131
1.00
343,676
576
1.13
319
32,539
2,393,019
1.00
5,689
0.93
343,756
640
1.25
382
39,067
2,393,372
1.00
5,336
0.87
343,822
704
1.38
445
44,250
2,393,667
1.00
5,041
0.82
343,875
768
1.50
508
50,055
2,393,906
1.00
4,802
0.78
343,919
832
1.63
571
56,557
2,394,100
1.00
4,608
0.75
343,955
896
1.75
634
63,271
2,394,256
1.00
4,452
0.73
343,984
960
1.88
697
69,808
2,394,386
1.00
4,322
0.70
344,008
1,024
2.00
760
76,190
2,394,490
1.00
4,218
0.69
344,027

This part of the recommendations on the size of the shared pool.

Shared Pool Size (M): to estimate the size of the shared pool

SP Size factr of: shared pool size factor

EST LC Size (M): the size of the estimated library cache occupied (library cache)

Est LC Mem Obj: cache in the number of objects

Est LC Time Saved (s): requires additional objects read into the shared pool time

Est LC Time Saved Factr: Impact Factor

Est LC Load Time (s): analysis of the time spent

Est LC Load Time Factr: analysis of the spending impact factor of the event

EST LC Mem Obj Hits (K): the number of memory object is found when we look at this list, consider this column Est LC Time Saved factr it Shared pool size of an analog re-object read into the shared pool impact. When this value change is small, or the constant increase in the Shared pool size would not make much sense!

SGA Target Advisory SGA Target Size (M) SGA Size Factor Est DB Time (s) Est
SGA Target Advisory
SGA Target Size (M) SGA Size Factor Est DB Time (s) Est Physical Reads
768
0.50
4,683,898
9,187,523,012
1,152
0.75
4,674,557
9,165,536,717
1,536
1.00
4,670,820
9,160,956,239
1,920
1.25
4,663,814
9,141,718,231
2,304
1.50
4,296,220
7,195,931,126
2,688
1.75
4,293,418
7,195,931,126
3,072
2.00
4,292,951
7,195,931,126
Part of this is a suggestion of the recommendations on the overall performance of SGA.
Part of this is a suggestion of the recommendations on the overall performance of SGA.
SGA Target Size (M): the estimated size of the SGA
SGA Size Factor: SGA size factor
EST DB Time (s): calculate the estimated size of the SGA DB Time
Segments by Logical Reads
Total Logical Reads: 3,662,795
Captured Segments account for 89.9% of Total
Owner
Tablespace Name
Object Name
Subobject Name Obj Type Logical Reads % Total
UNIPAYUSER CUCPAYPAYLAR T_PAY_SMSEND
UNIPAYUSER CUCPAYPAYLAR T_PAY_ORDER_INFO
TABLE
1,818,848
49.66
TABLE
186,880
5.10
UNIPAYUSER CUCPAYPAYLAR T_PAY_ORD_AUTO_NOTIFY
SYS SYSTEM I_OBJAUTH1
TABLE
159,648
4.36
INDEX
138,272
3.78
UNIPAYUSER CUCPAYPAYLAR T_PAY_USERINFO TABLE
111,616
3.05

Est Physical Reads: the number of physical reads from the above list you can see when the impact factor becomes SGA Size Factor = 1.5 times the number of physical time fell more objective, but the memory is sufficient! If sufficient SGA can be adjusted to 2304MB.

http://www.databaseskill.com/1544008/

26/09/2015

The The AWR (Automatic Workload Repository) - (4)! - Database - Database Skill

Página 4 de 4

Segments by Physical Reads Total Physical Reads: 96,430 Captured Segments account for 99.8% of Total
Segments by Physical Reads
Total Physical Reads: 96,430
Captured Segments account for 99.8% of Total
Owner
Tablespace Name
Object Name
Subobject Name Obj Type Physical Reads % Total
UNIPAYUSER CUCPAYPAYLAR T_PAY_USERINFO
UNIPAYUSER CUCPAYPAYLAR T_PAY_SMSEND
UNIPAYUSER CUCPAYPAYLAR UK_BINDAGR
UNIPAYUSER CUCPAYPAYLAR UK_USR_MBLBIND
UNIPAYUSER CUCPAYPAYLAR T_PAY_MERBINDAGR
TABLE
70,932
73.56
TABLE
21,318
22.11
INDEX
1,751
1.82
INDEX
673
0.70
TABLE
500
0.52

These two parts is a case to show the I / O from the object angle. Analysis of two pieces of information, you can know specifically which access to the object led to the decline of the I / O performance, this information will certainly be helpful for final positioning and problem-solving.

Segments by Buffer Busy Waits

% Of Capture shows% of Buffer Busy Waits for each top segment compared with total
% Of Capture shows% of Buffer Busy Waits for each top segment compared
with total Buffer Busy Waits for all segments captured by the Snapshot
Owner
Tablespace Name
Object Name
Subobject Name Obj Type Buffer Busy Waits % Of Capture
UNIPAYUSER CUCPAYPAYLAR PK_T_MAN_JOURNAL
This section can be seen very frequently accessed objects.
INDEX
2
100.00

AWR report which provides a very rich content, other parts do not be introduced! ! !

http://www.databaseskill.com/1544008/

26/09/2015