AWR - Automatic Workload Repository

AWR - Automatic Workload Repository - Database - Database Skill
Pgina 1 de 2
AWR - Automatic Workload Repository

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 resourceintensive 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
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
Pgina 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.
26/09/2015
AWR (Automatic Workload Repository) - comparative report generator (2)! - Data...
Pgina 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?
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.
17.
18.
DB Id
DB Id
DB Name
Inst Num Inst Num Instance
----------- ----------- ------------ -------- -------- -----------1293815896
1293815896 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?
Type Specified:
html
27.
28.
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
26/09/2015
41.
Using
Pgina 2 de 3
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.
48.
specifying a number lists all completed snapshots.
Pressing <return> without
49.
50.
51.
num_days :
--2?
52.
53.
Listing the last 2 days of Completed Snapshots
54.
55.
Snap
56.
Instance
DB Name
Snap Id
57.
------------ ------------ --------- ------------------ -----
58.
orcl
ORCL
Snap Started
Level
90 25 11 2011 02:17
59.
91 25 11 2011 03:00
60.
92 25 11 2011 04:00
61.
93 25 11 2011 05:00
62.
94 25 11 2011 06:00
63.
95 25 11 2011 07:00
64.
96 25 11 2011 08:00
66.
97 25 11 2011 23:59
67.
98 26 11 2011 01:00
65.
68.
69.
70.
71.
Specify the First Pair of Begin and End Snapshot Ids
72.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
73.
74.
begin_snap :
91
First Begin Snapshot Id specified: 91
--?
75.
76.
77.
end_snap :
First End
92
Snapshot Id specified: 92
--?
78.
79.
80.
81.
82.
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.
100.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
101.
102.
103.
104.
105.
num_days2 :
--2?
106.
107.
Listing the last 2 days of Completed Snapshots
108.
109.
Snap
110.
Instance
DB Name
Snap Id
111.
------------ ------------ --------- ------------------ -----
112.
orcl
ORCL
Snap Started
Level
90 25 11 2011 02:17
113.
91 25 11 2011 03:00
114.
92 25 11 2011 04:00
115.
93 25 11 2011 05:00
116.
94 25 11 2011 06:00
117.
95 25 11 2011 07:00
118.
96 25 11 2011 08:00
120.
97 25 11 2011 23:59
121.
98 26 11 2011 01:00
119.
122.
123.
124.
125.
Specify the Second Pair of Begin and End Snapshot Ids
126.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
127.
begin_snap2 :
92
--?
26/09/2015
128.
Pgina 3 de 3
Second Begin Snapshot Id specified: 92
129.
130.
131.
end_snap2 :
Second End
93
--?
132.
133.
134.
135.
Specify the Report Name
136.
~~~~~~~~~~~~~~~~~~~~~~~
137.
The default report file name is awrdiff_1_91_1_92.html
138.
press <return> to continue, otherwise enter an alternative.
To use this name,
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
26/09/2015
AWR (Automatic Workload Repository) - Overview (1)! - Database - Database Skill
Pgina 1 de 2
AWR (Automatic Workload Repository) - Overview (1)!

Tag: Session, report, html, Performance report Category: Database Author: s12248326 Date: 2011-03-04
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
04.
------------------------------------ ----------- ------------------------------
TYPE
05.
statistics_level
string
VALUE
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
26/09/2015
AWR (Automatic Workload Repository) - Overview (1)! - Database - Database Skill
10.
Pgina 2 de 2
With the Partitioning, OLAP, Data Mining and Real Application Testing options
11.
12.
13.
Current Instance
14.
~~~~~~~~~~~~~~~~
15.
16.
17.
18.
DB Id
DB Name
Inst Num Instance
----------- ------------ -------- -----------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.
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.
43.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
44.
45.
46.
47.
48.
49.
num_days :
--1?
50.
51.
Listing the last day's Completed Snapshots
52.
53.
Snap
54.
Instance
DB Name
Snap Id
55.
------------ ------------ --------- ------------------ -----
56.
orcl
ORCL
Snap Started
Level
13 07 10 2011 12:07
57.
14 07 10 2011 13:00
58.
15 07 10 2011 14:01
59.
16 07 10 2011 15:00
60.
17 07 10 2011 16:00
61.
18 07 10 2011 17:00
62.
63.
64.
65.
Specify the Begin and End Snapshot Ids
66.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
67.
68.
begin_snap :
17
Begin Snapshot Id specified: 17
--17?
69.
70.
71.
end_snap :
End
18
--18?
72.
73.
74.
75.
Specify the Report Name
76.
~~~~~~~~~~~~~~~~~~~~~~~
77.
The default report file name is awrrpt_1_17_18.html.
78.
press <return> to continue, otherwise enter an alternative.
To use this name,
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
26/09/2015
The The AWR (Automatic Workload Repository) - (3)! - Database - Database Skill
Pgina 1 de 8
The The AWR (Automatic Workload Repository) - (3)!

Tag: buffer, cache, integer, the sql Category: Database Author: libin37 Date: 2011-03-04
AWR a report in HTML format, for example:

DB Name
ORCL
DB Id
Instance Inst num Release RAC Host
1290103567 orcl
1 10.2.0.4.0 NO linux
Begin Snap:
End Snap:
Elapsed:
DB Time:
Snap Id
Snap Time
Sessions Cursors / Session
17 07-10 -11 16:00:10
22
2.6
18 07-10 -11 17:00:14
22
2.6
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
Buffer Cache:
Shared Pool Size:
Begin End
48M 48M Std Block Size:
92M 92M Log Buffer:
8K
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
Redo size:
Logical reads:
Block changes:
Physical reads:
Physical writes:
User calls:
Parses:
Hard parses:
Sorts:
Logons:
Executes:
Transactions:
% Blocks changed per Read:
Rollback per transaction%:
Per Second
638.10
6.96
2.20
0.02
0.26
0.05
0.76
0.00
0.51
0.02
1.61
0.09
Per Transaction
7,417.77
80.90
25.55
0.19
2.99
0.62
8.83
0.01
5.95
0.21
18.72
31.58 Recursive Call%:

0.00 Rows per Sort:
99.44
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
26/09/2015
Pgina 2 de 8
Transactions: per second (each transaction) number of transactions per second

Instance Efficiency Percentages (Target 100%)
In Buffer Nowait%:
Buffer Hit%:
Library Hit%:
Execute to Parse%:
Parse CPU to Parse Elapsd%:
100.00
99.77
99.89
52.83
14.55
Redo NOWAIT%:
In-memory Sort%:
Soft Parse%:
Latch Hit%:
% Non-Parse CPU:
100.00
100.00
99.89
100.00
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
Event
Waits
control file parallel

write
CPU time
log file parallel
write
db file parallel write
control file
sequential read
Time AVG Wait % Total Call

(s)
(ms)
Time
1,197
2
382
573
3,019
Wait
Class
System I /
279.9
O
64.0
System I /
61.7
O
System I /
50.2
O
System I /
27.4
O
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!
RAC Statistics
Begin
Number of Instances:
End
2
Global Cache Load Profile
Global Cache blocks received:

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

Buffer access - local cache%:
Buffer access - remote cache%:
Buffer access - disk%:
96.55
0.81
2.63
Global Cache and Enqueue Services - Workload Characteristics

Avg
global enqueue get time (ms):

Avg global cache cr block receive time (ms):
Avg global cache current block receive time (ms):
Avg global cache cr block build time (ms):
Avg global cache cr block send time (ms):
Global cache log flushes for cr blocks served%:
Avg global cache cr block flush time (ms):
Avg global cache current block pin time (ms):
Avg global cache current block send time (ms):
Global cache log flushes for current blocks served%:
Avg global cache current block flush time (ms):
0.0
0.4
0.5
0.0
0.0
0.1
0.0
0.0
0.0
0.0
26/09/2015
Pgina 3 de 8
Global Cache and Enqueue Services - Messaging Statistics

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:
0.0
0.2
0.0
0.0
0.0
29.88
23.50
46.62
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.
Time Model Statistics

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
Statistic Name
Time (s) % Of DB Time
sql execute elapsed time
9.42
88.00
DB CPU
7.66
71.60
parse time elapsed
2.86
26.68
hard parse elapsed time
2.43
22.67
PL / SQL execution elapsed time
1.65
15.39
PL / SQL compilation elapsed time
0.43
3.98
connection management call elapsed time
0.22
2.07
hard parse (sharing criteria) elapsed time
0.03
0.31
repeated bind elapsed time
0.01
0.10
hard parse (bind mismatch) elapsed time
0.01
0.08
sequence load elapsed time
0.00
0.01
DB time
10.70
background elapsed time
22.99
background cpu time
9.88
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 Waits % Time-outs Total Wait Time (s) Avg wait (ms) Waits / txn
System I / O 5,986
0.00
12
2
10.01
User I / O
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
Elap per Exec % Total DB SQL
Executions
SQL Module
(s)
(s)
(s)
Time
Id
2
1
60
0.03
14.89
1
1
2,154
0.00
13.44
OEM.SystemPool
0
41
0.01
4.34
94
0.00
4.19
OEM.Loader
0.19
3.48
OEM.BoundedPool
SQL Text
DECLARE job BINARY_INTEGER: = ...
begin MGMT_JOB_ENGINE.get_sche ...
The CALL
MGMT_ADMIN_DATA.EVALUATE_ ...
The INSERT INTO MGMT_METRICS_RAW (C.
..
begin setEMUserContext (: 1,: 2 ...
26/09/2015
0
0
0
0
119
18
0.00
0.02
3.32
2.70
OEM.SystemPool
60
0.00
2.67
OEM.SystemPool
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1,008
4
9
2,217
1
2,154
181
0.00
0.06
0.02
0.00
0.15
0.00
0.00
2.29
2.27
1.69
1.44
1.42
1.42
1.35
17
0.01
1.32
0
0
0
0
719
96
0.00
0.00
1.25
1.21
12
0.01
1.14
145
0.00
1.14
1,333
0.00
1.12
0.11
0.02
0.00
0.00
1.06
1.05
1.03
1.00
0
0
1
0
0
5
0
0
422
0
0
96
Sql execution time from long to short sort.
OEM.BoundedPool
OMS
OEM.SystemPool
OEM.Loader
Pgina 4 de 8
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 (ACTI. ..
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/ * OracleOEM * / DECLARE l_l ...

V3)
select order #, columns, types ...
The UPDATE MGMT_CURRENT_METRICS
OEM.Loader
SE ...
insert into wrh $ _pgastat (sn. ..
OEM.BoundedPool
The BEGIN EMD_LOADER.obtain_lock_f ...
select obj #, type #, ctime, mti ...
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

% Total DB Time is the Elapsed Time of the SQL statement divided into the Total Database Time multiplied by 100
CPU time Elapsed Time
CPU per Exec % Total DB SQL
Executions
SQL Module
(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
0
94
0.00
4.19
41
0.01
4.34
60
0.00
2.67
OEM.SystemPool
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1,008
1
2,154
2
4
719
2,217
0.00
0.15
0.00
0.07
0.04
0.00
0.00
2.29
1.42
1.42
3.48
2.27
1.25
1.44
OEM.SystemPool
OEM.BoundedPool
OEM.BoundedPool
12
0.01
1.14
1,333
0.00
1.12
0
0
0
0
0
0
0
0
0
0
18
181
422
9
96
0.01
0.00
0.00
0.01
0.00
2.70
1.35
1.03
1.69
1.21
17
0.00
1.32
0.00
0.01
0.00
0.02
1.14
1.05
1.00
1.06
0
0
145
0
0
5
0
0
96
0
0
1
sql cpu time consumed in descending sort.
OEM.Loader
SQL Text
..
The CALL
The BEGIN
EM_PING.RECORD_BATCH_HEA ...
insert into wrh $ _sga_target_ad ...
emagent @ linux (TNS V1/ * OracleOEM * / DECLARE l_l ...

V3)
OEM.Loader
SE ...
OMS
The BEGIN
OEM.Loader
OEM.BoundedPool
insert into wrh $ _pgastat (sn. ..
26/09/2015
Pgina 5 de 8
CPU Time (s): SQL consumed cpu time

Elapsed Time (s): sql execution time
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

Total Buffer Gets: 95,886
Captured SQL account for 64.7% of Total
Buffer
Executions
Gets
15,745
60
12,924
2,154
7,036
94
6,462
2,154
5,850
2,217
4,228
1,333
Gets per
%
CPU time Elapsed Time SQL
SQL Module
SQL Text
Exec
Total
(s)
(s)
Id
262.42
16.42
1.18
1.59
6.00
13.48
1.41
1.44
OEM.SystemPool begin MGMT_JOB_ENGINE.get_sche ...
74.85
7.34
0.34
0.45
OEM.Loader
The INSERT INTO MGMT_METRICS_RAW (C. ..
3.00
6.74
0.15
0.15
OEM.SystemPool SELECT JOB_ID, EXECUTION_ID, ...
2.64
6.10
0.13
0.15
3.17
4.41
0.12
0.12
OEM.Loader
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 The BEGIN EMD_NOTIFICATION.QUEUE_R ...
3,304
60
55.07
3.45
0.24
0.29
OEM.SystemPool 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
OEM.BoundedPool INSERT INTO MGMT_SEVERITY (ACTI. ..
2,152
213
10.10
2.24
0.05
0.05
select privilege #, level from ...
1,849
145
12.75
1.93
0.05
0.08
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
SELECT C.TARGET_GUID, C.METRI ...
1,119
2
559.50
1.17
0.15
0.37
OEM.BoundedPool begin setEMUserContext (: 1,: 2 ...
1,099
152
7.23
1.15
0.04
0.04
OEM.Loader
The INSERT INTO MGMT_SYSTEM_PERFOR ...
1,072
134
8.00
1.12
0.04
0.08
OEM.Loader
SELECT INSTANTIABLE, supertyp ...
981
9
109.00
1.02
0.06
0.18
OMS
SQL access to the memory number of data blocks, sorted in descending order.
Buffer Gets: the sql perform memory number of data blocks
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
Physical
Reads per
% CPU time Elapsed Time SQL
Executions
Reads
Exec
Total
(s)
(s)
Id
97
60
1.62 29.57
1.18
1.59
SQL Module
86
41
2.10
26.22
0.31
0.46
82
9.11
25.00
0.06
0.18
OMS
19
16
14
10
18
4
2
145
1.06
4.00
7.00
0.07
5.79
4.88
4.27
3.05
0.10
0.15
0.15
0.05
0.29
0.24
0.37
0.12
OEM.BoundedPool
OEM.BoundedPool
10
17
0.59
3.05
0.05
0.14
OEM.Loader
9
9
9
9
96
5
96
96
0.09
1.80
0.09
0.09
2.74
2.74
2.74
2.74
0.03
0.04
0.06
0.04
0.11
0.11
0.13
0.10
OEM.BoundedPool
SQL Text
The CALL
SELECT OWNER FROM DBA_PROCEDUR
to ...
The BEGIN
select / * + index (idl_sb4 $ i_id ...
26/09/2015
7
6
96
422
0.07
0.01
2.13
1.83
0.04
0.06
0.09
0.11
94
0.05
1.52
0.34
0.45
OEM.Loader
0.83
1.52
0.02
0.06
OEM.Loader
145
0.03
1.52
0.05
0.08
12
0.33
1.22
0.05
0.10
4
4
181
2,217
0.02
0.00
1.22
1.22
0.06
0.13
0.14
0.15
Pgina 6 de 8
select / * + index (idl_char $ i_i ...

..
The INSERT INTO
MGMT_STRING_METRIC ...
emagent @ linux (TNS V1/ * OracleOEM * / BEGIN IF (: ...

V3)
This section lists the SQL to perform a physical read, in descending order.
Physical Reads: sql physical number of Reading
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
2,217
2,214
2,154
2,154
Rows
Processed
1,416
2,214
0
2,154
1,333
1,333
Executions
Rows per
CPU per Exec Elap per Exec SQL
SQL Module
Exec
(s)
(s)
Id
0.64
0.00
0.00
1.00
0.00
0.00
EM_PING
0.00
0.00
0.00
OEM.SystemPool
1.00
0.00
0.00
OEM.SystemPool
1.00
0.00
0.00
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
This section lists the SQL execution times, installed in descending order sorting.
OEM.Loader
SQL Text
SELECT SYS_EXTRACT_UTC (SYSTIME. ..
SE ...
the lock table sys.col_usage $ in e ...
select type #, blocks, extents, ...

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
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
119
119
1.50
OEM.SystemPool
112
172
1.42
96
96
1.21
SQL Text
insert into sys.col_usage $ (ob. ..
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 INSTANTIABLE, supertyp ...
SELECT COUNT (*) FROM MGMT_PARA ...
26/09/2015
Pgina 7 de 8
96
96
1.21
select / * + index (idl_char $ i_i ...
96
96
1.21
96
96
1.21
select / * + index (idl_sb4 $ i_id ...
85
85
1.07
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 / * + rule * / bucket, end ...
27
823
select o.owner #, o.name, o.nam ...
25
202
This section lists the SQL multi-version information.
Version count: the number of the version of SQL
SQL ordered by Cluster Wait Time

Cluster Wait CWT% of
Time (s)
Elapsd Time
Elapsed
Time (s)
CPU
SQL
Executions
time (s)
Id
1.61
28.98
5.55
4.23
85
1.18
3.86
30.45
28.35
180
1.15
65.96
1.74
0.71
890
0.70
75.76
0.93
0.30
890
0.69
1.72
40.04
2.79
0.63
46.16
1.37
0.38
966
0.34
64.22
0.53
0.18
774
0.23
18.63
1.23
0.20
1,880
0.23
74.21
0.30
0.09
890
0.20
3.08
6.43
0.15
1,880
0.19
43.74
0.43
0.10
935
0.16
2.68
6.12
0.22
4,398
0.12
18.49
0.64
0.57
47
0.11
9.62
1.11
0.06
966
0.10
0.08
0.08
0.08
0.08
0.08
3.19
13.09
7.62
1.88
17.65
2.11
3.21
0.64
1.06
4.17
0.44
3.68
2.55
0.09
0.18
0.13
0.10
0.22
1
1,882
19,140
4,176
1,703
18,079
0.06
17.83
0.35
0.27
25
0.06
0.02
0.01
0.01
16.78
1.36
2.14
5.44
0.34
1.27
0.66
0.21
0.03
0.00
0.02
0.05
1,889
2,270
4,542
819
SQL Module
serv_proc @
zfyw_payoln (TNS V1V3)
JDBC Thin Client
serv_proc @
serv_proc @
PL / SQL Developer
serv_proc @
serv_proc @
JDBC Thin Client
serv_proc @
JDBC Thin Client
serv_proc @
JDBC Thin Client
serv_proc @
serv_proc @
plsqldev.exe
JDBC Thin Client
JDBC Thin Client
JDBC Thin Client
JDBC Thin Client
serv_proc @
JDBC Thin Client
JDBC Thin Client
JDBC Thin Client
SQL Text
SELECT * FROM (SELECT T1.MERNO ...
select ID, DESTNO, LIVETIME, C. ..
The INSERT INTO T_PAY_ORDER_INFO (I. ..
select count (t.id) +1, to_char (...

- 3.2 the number of active users daily report SQL - can not be
divided into independent registered or Wal ...
The INSERT INTO T_PAY_SYSTEM_JOURN ...
As UPDATE T_PAY_SYSTEM_JOURNAL SE ...

insert into t_pay_merbindagr (a. ..
SELECT ID, to_char (amount), ST ...
select agrno, status from t_pa ...
As UPDATE T_PAY_SYSTEM_JOURNAL SE ...
select * from (select t.usern ...
UPDATE T_PAY_ORD_AUTO_NOTIFY, S. ..
select t.agrno from T_PAY_MERB ...

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 ...
UPDATE T_PAY_ORD_AUTO_NOTIFY, S. ..
insert into T_PAY_SMSEND t (ti..
select userno from t_pay_useri ...
select t.STATUS, t.REGTYPE, t ....
select / * + rule * / bucket, end ...
26/09/2015
0.01
2.04
0.48
0.01
4,542
JDBC Thin Client
0.01
1.38
0.61
0.03
5,646
JDBC Thin Client
0.01
25.54
0.03
0.00
18
JDBC Thin Client
0.01
0.66
0.84
0.06
3,764
JDBC Thin Client
0.01
11.51
0.05
0.04
4
plsqldev.exe
0.01
3.24
0.16
0.14
1
0.01
1.31
0.40
0.01
1,933
JDBC Thin Client
0.01
9.83
0.05
0.02
132
plsqldev.exe
This part only in a RAC environment only, lists the instance of sharing data between the wait.
Pgina 8 de 8
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 (snap_i. ..
select * from (select count (* ...
select value (p $) from "XDB". "X. ..
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
26/09/2015
Pgina 1 de 4
The The AWR (Automatic Workload Repository) - (4)!

Tag: buffer, cache, session, library Category: Database Author: jlh869 Date: 2011-01-10
Continued
access front
Instance Activity Stats

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 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
Reads Av Reads / s AV Rd (ms) Av Blks / Rd Writes Av Writes / s Buffer Waits AV BUF Wt (ms)
SYSAUX
/ U01/app/oracle/oradata/orcl/sysaux01.dbf
227
0
9.96
1.01
420
0
0
0.00
SYSTEM
/ U01/app/oracle/oradata/orcl/system01.dbf
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
26/09/2015
Pgina 2 de 4
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 / 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.
26/09/2015
Pgina 3 de 4
Shared Pool Advisory

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
Size (M)
factr is
(M)
Obj
Saved (s)
320
0.63
69
7,243
2,390,521
384
0.75
131
13,655
2,391,420
448
0.88
193
19,589
2,392,063
512
1.00
256
26,030
2,392,577
576
1.13
319
32,539
2,393,019
640
1.25
382
39,067
2,393,372
704
1.38
445
44,250
2,393,667
768
1.50
508
50,055
2,393,906
832
1.63
571
56,557
2,394,100
896
1.75
634
63,271
2,394,256
960
1.88
697
69,808
2,394,386
1,024
2.00
760
76,190
2,394,490
This part of the recommendations on the size of the shared pool.
Est LC Time
Saved Factr
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
Est LC Load
Time (s)
8,187
7,288
6,645
6,131
5,689
5,336
5,041
4,802
4,608
4,452
4,322
4,218
Est LC Load
Est LC Mem Obj
Time Factr
Hits (K)
1.34
343,271
1.19
343,453
1.08
343,577
1.00
343,676
0.93
343,756
0.87
343,822
0.82
343,875
0.78
343,919
0.75
343,955
0.73
343,984
0.70
344,008
0.69
344,027
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 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.
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
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.
Segments by Logical Reads

Total Logical Reads: 3,662,795
Captured Segments account for 89.9% of Total
Owner
UNIPAYUSER
UNIPAYUSER
UNIPAYUSER
SYS
UNIPAYUSER
Tablespace Name
CUCPAYPAYLAR
CUCPAYPAYLAR
CUCPAYPAYLAR
SYSTEM
CUCPAYPAYLAR
Object Name
Subobject Name
T_PAY_SMSEND
T_PAY_ORDER_INFO
T_PAY_ORD_AUTO_NOTIFY
I_OBJAUTH1
T_PAY_USERINFO
Obj Type Logical Reads % Total

TABLE
1,818,848
49.66
TABLE
186,880
5.10
TABLE
159,648
4.36
INDEX
138,272
3.78
TABLE
111,616
3.05
26/09/2015
Pgina 4 de 4
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
TABLE
70,932
73.56
UNIPAYUSER CUCPAYPAYLAR T_PAY_SMSEND
TABLE
21,318
22.11
UNIPAYUSER CUCPAYPAYLAR UK_BINDAGR
INDEX
1,751
1.82
UNIPAYUSER CUCPAYPAYLAR UK_USR_MBLBIND
INDEX
673
0.70
UNIPAYUSER CUCPAYPAYLAR T_PAY_MERBINDAGR
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 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
INDEX
2
100.00
This section can be seen very frequently accessed objects.
AWR report which provides a very rich content, other parts do not be introduced! ! !
26/09/2015

AWR - Automatic Workload Repository

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AWR - Automatic Workload Repository

Uploaded by

Copyright:

Available Formats

AWR - Automatic Workload Repository - Database - Database Skill

AWR - Automatic Workload Repository

Archive, it is time to read ~

AWR - Automatic Workload Repository - Database - Database Skill

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

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

Gestiona Organiza Crece

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

SQL> select * from dba_hist_baseline;

DBID BASELINE_ID BASELINE_NAM START_SNAP_ID START_SNAP_TIME

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

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

SQL> select * from dba_hist_baseline;

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

SQL*Plus: Release 10.2.0.4.0 - Production on

Copyright (c) 1982, 2007, Oracle.

All Rights Reserved.

Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production

Inst Num Inst Num Instance

----------- ----------- ------------ -------- -------- -----------1293815896

Specify the Report Type

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

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

Instances in this Workload Repository schema

Inst Num DB Name

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

Database Id and Instance Number for the First Pair of Snapshots

Using 1293815896 for Database Id for the first pair of snapshots

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

1 for Instance Number for the first pair of snapshots

Specify the number of days of snapshots to choose from

(n) days of snapshots being listed.

specifying a number lists all completed snapshots.

Pressing <return> without

Listing the last 2 days of Completed Snapshots

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

Specify the First Pair of Begin and End Snapshot Ids

First Begin Snapshot Id specified: 91

Instances in this Workload Repository schema

Inst Num DB Name

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

Database Id and Instance Number for the Second Pair of Snapshots

Using 1293815896 for Database Id for the second pair of snapshots

1 for Instance Number for the second pair of snapshots

Specify the number of days of snapshots to choose from

(n) days of snapshots being listed.

specifying a number lists all completed snapshots.

Pressing <return> without

Listing the last 2 days of Completed Snapshots

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

Specify the Second Pair of Begin and End Snapshot Ids

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

Second Begin Snapshot Id specified: 92

Specify the Report Name

The default report file name is awrdiff_1_91_1_92.html

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

To use this name,

Using the report name awrdiff_1_91_1_92.html

Report written to awrdiff_1_91_1_92.html

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

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

SQL> select * from dba_hist_wr_control;

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

1293815896 +00000 01:00:00.0