一, 前言
- 当我们把一条sql送到数据库去执行的时候，我们要知道，什么时候用到cpu，什么时候用到内存，什么时候用到io
在看性能指标的时候，心里先要明白，数据库出现性能问题，一般都在三个地方，io，内存，cpu，这三个又是息息相关的（ps：我们先假设这个三个地方都没有物理上的故障），当io负载增大时，肯定需要更多的内存来存放，同时也需要cpu花费更多的时间来过滤这些数据，相反，cpu时间花费多的话，有可能是解析sql语句，也可能是过滤太多的数据，到不一定是和io或内存有关系了 。
1. cpu：
解析sql语句，尝试多个执行计划，最后生成一个数据库认为是比较好的执行计划，不一定是最优的，因为关联表太多的时候，数据库并不会穷举所有的执行计划，这会消耗太多的时间，oracle怎么就知道这条数据时你要，另一个就不是你要的呢，这是需要cpu来过滤的
2. 内存：
sql语句和执行计划都需要在内存保留一段时间，还有取到的数据，根据lru算法也会尽量在内存中保留，在执行sql语句过程中，各种表之间的连接，排序等操作也要占用内存
3. io：
如果需要的数据在内存中没有，则需要到磁盘中去取，就会用到物理io了，还有表之间的连接数据太多，以及排序等操作内存放不下的时候，也需要用到临时表空间，也就用到物理io了
这里有一点说明的是，虽然oracle占用了8G的内存，但pga一般只占8G的20%，对于专用服务器模式，每次执行sql语句，表数据的运算等操作，都在pga中进行的，也就是说只能用1.6G左右的内存，如果多个用户都执行 多表关联，而且表数据又多，再加上关联不当的话，内存就成为瓶颈了，所有优化sql很重要的一点就是，减少逻辑读和物理读。
二,生成AWR报告
01 AWR的数据主要有两部分组成：
1）保存在内存中的系统负载和性能统计数据，主要通过v$视图查询 ；
2）mmon进程定期以快照(snapshot)的方式将内存中的AWR数据保存到SYSAUX表空间中，主要通过DBA_*视图访问。
02. AWR快照的生成
默认情况下，每隔一小时自动产生一个快照，保存最近7天的信息，可以通过以下语句查询：
SQL> select SNAP_INTERVAL,RETENTION from dba_hist_wr_control;
SNAP_INTERVAL
---------------------------------------------------------------------------
RETENTION
---------------------------------------------------------------------------
+00000 01:00:00.0
+00008 00:00:00.0
可以通过以下语句修改时间间隔和保存时间(以分钟为单位)：
exec dbms_workload_repository.modify_snapshot_settings(interval => 30, retention = > 10*24*60);
也可以根据需要随时手动生成快照：
exec dbms_workload_repository.create_snapshot;
03. AWR报告的生成
以sysdba运行如下命令：
@?/rdbms/admin/awrrpt.sql
[oracle@node12c01 ~]$ sqlplus / as sysdba
SQL*Plus: Release 12.2.0.1.0 Production on Wed Apr 17 02:20:31 2019
Copyright (c) 1982, 2016, Oracle. All rights reserved.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
SQL> @?/rdbms/admin/awrrpt.sql --执行生成报表
Specify the Report Type
~~~~~~~~~~~~~~~~~~~~~~~
AWR reports can be generated in the following formats. Please enter the
name of the format at the prompt. Default value is 'html'.
'html' HTML format (default)
'text' Text format
'active-html' Includes Performance Hub active report
Enter value for report_type: html --选择你要生成的类型,类型有上显示
old 1: select 'Type Specified: ',lower(nvl('&&report_type','html')) report_type from dual
new 1: select 'Type Specified: ',lower(nvl('html','html')) report_type from dual
Type Specified: html
old 1: select '&&report_type' report_type_def from dual
new 1: select 'html' report_type_def from dual
old 1: select '&&view_loc' view_loc_def from dual
new 1: select 'AWR_PDB' view_loc_def from dual
Current Instance
~~~~~~~~~~~~~~~~
DB Id DB Name Inst Num Instance Container Name
-------------- -------------- -------------- -------------- --------------
1532278336 ORCL 1 orcl CDB$ROOT
Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id Inst Num DB Name Instance Host
------------ ---------- --------- ---------- ------
* 1532278336 1 ORCL orcl node12c01
Using 1532278336 for database Id
Using 1 for instance number
Specify the number of days of snapshots to choose from
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Entering the number of days (n) will result in the most recent
(n) days of snapshots being listed. Pressing <return> without
specifying a number lists all completed snapshots.
Enter value for num_days: 7 --选择时间范围
Listing the last 7 days of Completed Snapshots
Instance DB Name Snap Id Snap Started Snap Level
------------ ------------ ---------- ------------------ ----------
orcl ORCL 213 11 Apr 2019 00:00 1
214 11 Apr 2019 01:00 1
215 11 Apr 2019 02:00 1
216 11 Apr 2019 03:00 1
217 11 Apr 2019 04:00 1
218 11 Apr 2019 05:00 1
219 11 Apr 2019 06:00 1
220 11 Apr 2019 07:00 1
221 11 Apr 2019 08:00 1
222 11 Apr 2019 09:00 1
223 11 Apr 2019 10:00 1
224 11 Apr 2019 11:00 1
225 11 Apr 2019 12:00 1
226 11 Apr 2019 13:00 1
227 11 Apr 2019 14:00 1
228 11 Apr 2019 15:00 1
229 11 Apr 2019 16:00 1
230 11 Apr 2019 17:00 1
231 11 Apr 2019 18:00 1
232 11 Apr 2019 19:00 1
233 11 Apr 2019 20:00 1
234 11 Apr 2019 21:00 1
235 11 Apr 2019 22:00 1
236 11 Apr 2019 23:00 1
237 12 Apr 2019 00:00 1
238 12 Apr 2019 01:00 1
239 12 Apr 2019 02:00 1
240 12 Apr 2019 03:00 1
241 12 Apr 2019 04:00 1
242 12 Apr 2019 05:00 1
243 12 Apr 2019 06:00 1
244 12 Apr 2019 07:00 1
245 12 Apr 2019 08:00 1
246 12 Apr 2019 09:00 1
247 12 Apr 2019 10:00 1
248 12 Apr 2019 11:00 1
249 12 Apr 2019 12:00 1
250 12 Apr 2019 13:00 1
251 12 Apr 2019 14:00 1
252 12 Apr 2019 15:00 1
253 12 Apr 2019 16:00 1
254 12 Apr 2019 17:00 1
255 12 Apr 2019 18:00 1
256 12 Apr 2019 19:00 1
257 12 Apr 2019 20:00 1
258 12 Apr 2019 21:00 1
259 12 Apr 2019 22:00 1
260 12 Apr 2019 23:00 1
261 13 Apr 2019 00:00 1
262 13 Apr 2019 01:00 1
263 13 Apr 2019 02:00 1
264 13 Apr 2019 03:00 1
265 13 Apr 2019 04:00 1
266 13 Apr 2019 05:00 1
267 13 Apr 2019 06:00 1
268 13 Apr 2019 07:00 1
Instance DB Name Snap Id Snap Started Snap Level
------------ ------------ ---------- ------------------ ----------
orcl ORCL 269 13 Apr 2019 08:00 1
270 13 Apr 2019 09:00 1
271 13 Apr 2019 10:00 1
272 13 Apr 2019 11:00 1
273 13 Apr 2019 12:00 1
274 13 Apr 2019 13:00 1
275 13 Apr 2019 14:00 1
276 13 Apr 2019 15:00 1
277 13 Apr 2019 16:00 1
278 13 Apr 2019 17:00 1
279 13 Apr 2019 18:00 1
280 13 Apr 2019 19:00 1
281 13 Apr 2019 20:00 1
282 13 Apr 2019 21:00 1
283 13 Apr 2019 22:00 1
284 13 Apr 2019 23:00 1
285 14 Apr 2019 00:00 1
286 14 Apr 2019 01:00 1
287 14 Apr 2019 02:00 1
288 14 Apr 2019 03:00 1
289 14 Apr 2019 04:00 1
290 14 Apr 2019 05:00 1
291 14 Apr 2019 06:00 1
292 14 Apr 2019 07:00 1
293 14 Apr 2019 08:00 1
294 14 Apr 2019 09:00 1
295 14 Apr 2019 10:00 1
296 14 Apr 2019 11:00 1
297 14 Apr 2019 12:00 1
298 14 Apr 2019 13:00 1
299 14 Apr 2019 14:00 1
300 14 Apr 2019 15:00 1
301 14 Apr 2019 16:00 1
302 14 Apr 2019 17:00 1
303 14 Apr 2019 18:00 1
304 14 Apr 2019 19:00 1
305 14 Apr 2019 20:00 1
306 14 Apr 2019 21:00 1
307 14 Apr 2019 22:00 1
308 14 Apr 2019 23:00 1
309 15 Apr 2019 00:00 1
310 15 Apr 2019 01:00 1
311 15 Apr 2019 02:00 1
312 15 Apr 2019 03:00 1
313 15 Apr 2019 04:00 1
314 15 Apr 2019 05:00 1
315 15 Apr 2019 06:00 1
316 15 Apr 2019 07:00 1
317 15 Apr 2019 08:00 1
318 15 Apr 2019 09:00 1
319 15 Apr 2019 10:00 1
320 15 Apr 2019 11:00 1
321 15 Apr 2019 12:00 1
322 15 Apr 2019 13:00 1
323 15 Apr 2019 14:00 1
324 15 Apr 2019 15:00 1
Instance DB Name Snap Id Snap Started Snap Level
------------ ------------ ---------- ------------------ ----------
orcl ORCL 325 15 Apr 2019 16:00 1
326 15 Apr 2019 17:00 1
327 15 Apr 2019 18:00 1
328 15 Apr 2019 19:00 1
329 15 Apr 2019 20:00 1
330 15 Apr 2019 21:00 1
331 15 Apr 2019 22:00 1
332 15 Apr 2019 23:00 1
333 16 Apr 2019 00:00 1
334 16 Apr 2019 01:00 1
335 16 Apr 2019 02:00 1
336 16 Apr 2019 03:00 1
337 16 Apr 2019 04:00 1
338 16 Apr 2019 05:00 1
339 16 Apr 2019 06:00 1
340 16 Apr 2019 07:00 1
341 16 Apr 2019 08:00 1
342 16 Apr 2019 09:00 1
343 16 Apr 2019 10:00 1
344 16 Apr 2019 11:00 1
345 16 Apr 2019 12:00 1
346 16 Apr 2019 13:00 1
347 16 Apr 2019 14:00 1
348 16 Apr 2019 15:00 1
349 16 Apr 2019 16:00 1
350 16 Apr 2019 17:00 1
351 16 Apr 2019 18:00 1
352 16 Apr 2019 19:00 1
353 16 Apr 2019 20:00 1
354 16 Apr 2019 21:00 1
355 16 Apr 2019 22:00 1
356 16 Apr 2019 23:00 1
357 17 Apr 2019 00:00 1
358 17 Apr 2019 01:00 1
359 17 Apr 2019 02:00 1
Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap: 213 --生成开始的id
Begin Snapshot Id specified: 213
Enter value for end_snap: 359 --生成结束的id
End Snapshot Id specified: 359
Specify the Report Name
~~~~~~~~~~~~~~~~~~~~~~~
The default report file name is awrrpt_1_213_359.html. To use this name,
press <return> to continue, otherwise enter an alternative.
Enter value for report_name: 选择自己的名字
Using the report name awrrpt_1_213_359.html
具体操作:
1 [oracle@node12c01 ~]$ sqlplus / as sysdba
2
3 SQL*Plus: Release 12.2.0.1.0 Production on Wed Apr 17 02:20:31 2019
4
5 Copyright (c) 1982, 2016, Oracle. All rights reserved.
6
7
8 Connected to:
9 Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
10
11 SQL> @?/rdbms/admin/awrrpt.sql --执行生成报表
12
13 Specify the Report Type
14 ~~~~~~~~~~~~~~~~~~~~~~~
15 AWR reports can be generated in the following formats. Please enter the
16 name of the format at the prompt. Default value is 'html'.
17
18 'html' HTML format (default)
19 'text' Text format
20 'active-html' Includes Performance Hub active report
21
22 Enter value for report_type: html --选择你要生成的类型,类型有上显示
23 old 1: select 'Type Specified: ',lower(nvl('&&report_type','html')) report_type from dual
24 new 1: select 'Type Specified: ',lower(nvl('html','html')) report_type from dual
25
26 Type Specified: html
27
28 old 1: select '&&report_type' report_type_def from dual
29 new 1: select 'html' report_type_def from dual
30
31
32
33 old 1: select '&&view_loc' view_loc_def from dual
34 new 1: select 'AWR_PDB' view_loc_def from dual
35
36
37
38 Current Instance
39 ~~~~~~~~~~~~~~~~
40 DB Id DB Name Inst Num Instance Container Name
41 -------------- -------------- -------------- -------------- --------------
42 1532278336 ORCL 1 orcl CDB$ROOT
43
44
45
46
47
48
49
50
51
52
53
54 Instances in this Workload Repository schema
55 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
56 DB Id Inst Num DB Name Instance Host
57 ------------ ---------- --------- ---------- ------
58 * 1532278336 1 ORCL orcl node12c01
59
60 Using 1532278336 for database Id
61 Using 1 for instance number
62
63
64 Specify the number of days of snapshots to choose from
65 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
66 Entering the number of days (n) will result in the most recent
67 (n) days of snapshots being listed. Pressing <return> without
68 specifying a number lists all completed snapshots.
69
70
71 Enter value for num_days: 7 --选择时间范围
72
73 Listing the last 7 days of Completed Snapshots
74 Instance DB Name Snap Id Snap Started Snap Level
75 ------------ ------------ ---------- ------------------ ----------
76
77 orcl ORCL 213 11 Apr 2019 00:00 1
78 214 11 Apr 2019 01:00 1
79 215 11 Apr 2019 02:00 1
80 216 11 Apr 2019 03:00 1
81 217 11 Apr 2019 04:00 1
82 218 11 Apr 2019 05:00 1
83 219 11 Apr 2019 06:00 1
84 220 11 Apr 2019 07:00 1
85 221 11 Apr 2019 08:00 1
86 222 11 Apr 2019 09:00 1
87 223 11 Apr 2019 10:00 1
88 224 11 Apr 2019 11:00 1
89 225 11 Apr 2019 12:00 1
90 226 11 Apr 2019 13:00 1
91 227 11 Apr 2019 14:00 1
92 228 11 Apr 2019 15:00 1
93 229 11 Apr 2019 16:00 1
94 230 11 Apr 2019 17:00 1
95 231 11 Apr 2019 18:00 1
96 232 11 Apr 2019 19:00 1
97 233 11 Apr 2019 20:00 1
98 234 11 Apr 2019 21:00 1
99 235 11 Apr 2019 22:00 1
100 236 11 Apr 2019 23:00 1
101 237 12 Apr 2019 00:00 1
102 238 12 Apr 2019 01:00 1
103 239 12 Apr 2019 02:00 1
104 240 12 Apr 2019 03:00 1
105 241 12 Apr 2019 04:00 1
106 242 12 Apr 2019 05:00 1
107 243 12 Apr 2019 06:00 1
108 244 12 Apr 2019 07:00 1
109 245 12 Apr 2019 08:00 1
110 246 12 Apr 2019 09:00 1
111 247 12 Apr 2019 10:00 1
112 248 12 Apr 2019 11:00 1
113 249 12 Apr 2019 12:00 1
114 250 12 Apr 2019 13:00 1
115 251 12 Apr 2019 14:00 1
116 252 12 Apr 2019 15:00 1
117 253 12 Apr 2019 16:00 1
118 254 12 Apr 2019 17:00 1
119 255 12 Apr 2019 18:00 1
120 256 12 Apr 2019 19:00 1
121 257 12 Apr 2019 20:00 1
122 258 12 Apr 2019 21:00 1
123 259 12 Apr 2019 22:00 1
124 260 12 Apr 2019 23:00 1
125 261 13 Apr 2019 00:00 1
126 262 13 Apr 2019 01:00 1
127 263 13 Apr 2019 02:00 1
128 264 13 Apr 2019 03:00 1
129 265 13 Apr 2019 04:00 1
130 266 13 Apr 2019 05:00 1
131 267 13 Apr 2019 06:00 1
132 268 13 Apr 2019 07:00 1
133 Instance DB Name Snap Id Snap Started Snap Level
134 ------------ ------------ ---------- ------------------ ----------
135
136 orcl ORCL 269 13 Apr 2019 08:00 1
137 270 13 Apr 2019 09:00 1
138 271 13 Apr 2019 10:00 1
139 272 13 Apr 2019 11:00 1
140 273 13 Apr 2019 12:00 1
141 274 13 Apr 2019 13:00 1
142 275 13 Apr 2019 14:00 1
143 276 13 Apr 2019 15:00 1
144 277 13 Apr 2019 16:00 1
145 278 13 Apr 2019 17:00 1
146 279 13 Apr 2019 18:00 1
147 280 13 Apr 2019 19:00 1
148 281 13 Apr 2019 20:00 1
149 282 13 Apr 2019 21:00 1
150 283 13 Apr 2019 22:00 1
151 284 13 Apr 2019 23:00 1
152 285 14 Apr 2019 00:00 1
153 286 14 Apr 2019 01:00 1
154 287 14 Apr 2019 02:00 1
155 288 14 Apr 2019 03:00 1
156 289 14 Apr 2019 04:00 1
157 290 14 Apr 2019 05:00 1
158 291 14 Apr 2019 06:00 1
159 292 14 Apr 2019 07:00 1
160 293 14 Apr 2019 08:00 1
161 294 14 Apr 2019 09:00 1
162 295 14 Apr 2019 10:00 1
163 296 14 Apr 2019 11:00 1
164 297 14 Apr 2019 12:00 1
165 298 14 Apr 2019 13:00 1
166 299 14 Apr 2019 14:00 1
167 300 14 Apr 2019 15:00 1
168 301 14 Apr 2019 16:00 1
169 302 14 Apr 2019 17:00 1
170 303 14 Apr 2019 18:00 1
171 304 14 Apr 2019 19:00 1
172 305 14 Apr 2019 20:00 1
173 306 14 Apr 2019 21:00 1
174 307 14 Apr 2019 22:00 1
175 308 14 Apr 2019 23:00 1
176 309 15 Apr 2019 00:00 1
177 310 15 Apr 2019 01:00 1
178 311 15 Apr 2019 02:00 1
179 312 15 Apr 2019 03:00 1
180 313 15 Apr 2019 04:00 1
181 314 15 Apr 2019 05:00 1
182 315 15 Apr 2019 06:00 1
183 316 15 Apr 2019 07:00 1
184 317 15 Apr 2019 08:00 1
185 318 15 Apr 2019 09:00 1
186 319 15 Apr 2019 10:00 1
187 320 15 Apr 2019 11:00 1
188 321 15 Apr 2019 12:00 1
189 322 15 Apr 2019 13:00 1
190 323 15 Apr 2019 14:00 1
191 324 15 Apr 2019 15:00 1
192 Instance DB Name Snap Id Snap Started Snap Level
193 ------------ ------------ ---------- ------------------ ----------
194
195 orcl ORCL 325 15 Apr 2019 16:00 1
196 326 15 Apr 2019 17:00 1
197 327 15 Apr 2019 18:00 1
198 328 15 Apr 2019 19:00 1
199 329 15 Apr 2019 20:00 1
200 330 15 Apr 2019 21:00 1
201 331 15 Apr 2019 22:00 1
202 332 15 Apr 2019 23:00 1
203 333 16 Apr 2019 00:00 1
204 334 16 Apr 2019 01:00 1
205 335 16 Apr 2019 02:00 1
206 336 16 Apr 2019 03:00 1
207 337 16 Apr 2019 04:00 1
208 338 16 Apr 2019 05:00 1
209 339 16 Apr 2019 06:00 1
210 340 16 Apr 2019 07:00 1
211 341 16 Apr 2019 08:00 1
212 342 16 Apr 2019 09:00 1
213 343 16 Apr 2019 10:00 1
214 344 16 Apr 2019 11:00 1
215 345 16 Apr 2019 12:00 1
216 346 16 Apr 2019 13:00 1
217 347 16 Apr 2019 14:00 1
218 348 16 Apr 2019 15:00 1
219 349 16 Apr 2019 16:00 1
220 350 16 Apr 2019 17:00 1
221 351 16 Apr 2019 18:00 1
222 352 16 Apr 2019 19:00 1
223 353 16 Apr 2019 20:00 1
224 354 16 Apr 2019 21:00 1
225 355 16 Apr 2019 22:00 1
226 356 16 Apr 2019 23:00 1
227 357 17 Apr 2019 00:00 1
228 358 17 Apr 2019 01:00 1
229 359 17 Apr 2019 02:00 1
230
231
232 Specify the Begin and End Snapshot Ids
233 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
234 Enter value for begin_snap: 213 --生成开始的id
235 Begin Snapshot Id specified: 213
236
237 Enter value for end_snap: 359 --生成结束的id
238 End Snapshot Id specified: 359
239
240
241
242 Specify the Report Name
243 ~~~~~~~~~~~~~~~~~~~~~~~
244 The default report file name is awrrpt_1_213_359.html. To use this name,
245 press <return> to continue, otherwise enter an alternative.
246
247 Enter value for report_name: 选择自己的名字
248
249 Using the report name awrrpt_1_213_359.html
250
251 .........................................
252
253 <td class='awrnc'>
254 CDB$ROOT
255 </td></tr>
256 </table><p />
257 <hr align="left" width="20%" /><p />
258 <a class="awr" href="#36">Back to init.ora Parameters</a>
259 <br /><a class="awr" href="#top">Back to Top</a><p />
260 <p />
261 <a class="awr" name="99995"></a>
262 <h2>ADDM Task ADDM:1532278336_1_282</h2>
263 <pre>
264 ADDM Report for Task 'ADDM:1532278336_1_282'
265 --------------------------------------------
266
267 Analysis Period
268 ---------------
269 AWR snapshot range from 281 to 282.
270 Time period starts at 13-APR-19 08.00.39 PM
271 Time period ends at 13-APR-19 09.00.44 PM
272
273 Analysis Target
274 ---------------
275 Database 'ORCL' with DB ID 1532278336.
276 Database version 12.2.0.1.0.
277 ADDM performed an analysis of instance orcl, numbered 1 and hosted at
278 node12c01.
279
280 Activity During the Analysis Period
281 -----------------------------------
282 Total database time was 191 seconds.
283 The average number of active sessions was .05.
284
285
286 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
287 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
288
289 There are no findings to report.
290
291 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
292 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
293
294 Additional Information
295 ----------------------
296
297 Miscellaneous Information
298 -------------------------
299 There was no significant database activity to run the ADDM.
300
301 The database's maintenance windows were active during 99% of the analysis
302 period.
303
304 </pre>
305 <h2>ADDM Task ADDM:1532278336_1_306</h2>
306 <pre>
307 ADDM Report for Task 'ADDM:1532278336_1_306'
308 --------------------------------------------
309
310 Analysis Period
311 ---------------
312 AWR snapshot range from 305 to 306.
313 Time period starts at 14-APR-19 08.00.33 PM
314 Time period ends at 14-APR-19 09.00.38 PM
315
316 Analysis Target
317 ---------------
318 Database 'ORCL' with DB ID 1532278336.
319 Database version 12.2.0.1.0.
320 ADDM performed an analysis of instance orcl, numbered 1 and hosted at
321 node12c01.
322
323 Activity During the Analysis Period
324 -----------------------------------
325 Total database time was 180 seconds.
326 The average number of active sessions was .05.
327
328
329 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
330 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
331
332 There are no findings to report.
333
334 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
335 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
336
337 Additional Information
338 ----------------------
339
340 Miscellaneous Information
341 -------------------------
342 There was no significant database activity to run the ADDM.
343
344 The database's maintenance windows were active during 100% of the analysis
345 period.
346
347 </pre>
348 <h2>ADDM Task ADDM:1532278336_1_305</h2>
349 <pre>
350 ADDM Report for Task 'ADDM:1532278336_1_305'
351 --------------------------------------------
352
353 Analysis Period
354 ---------------
355 AWR snapshot range from 304 to 305.
356 Time period starts at 14-APR-19 07.00.28 PM
357 Time period ends at 14-APR-19 08.00.33 PM
358
359 Analysis Target
360 ---------------
361 Database 'ORCL' with DB ID 1532278336.
362 Database version 12.2.0.1.0.
363 ADDM performed an analysis of instance orcl, numbered 1 and hosted at
364 node12c01.
365
366 Activity During the Analysis Period
367 -----------------------------------
368 Total database time was 168 seconds.
369 The average number of active sessions was .05.
370
371
372 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
373 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
374
375 There are no findings to report.
376
377 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
378 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
379
380 Additional Information
381 ----------------------
382
383 Miscellaneous Information
384 -------------------------
385 There was no significant database activity to run the ADDM.
386
387 The database's maintenance windows were active during 99% of the analysis
388 period.
389
390 </pre>
391 <br /><a class="awr" href="#top">Back to Top</a><p />
392 <p />
393 <p />
394 <p />
395 <p />
396 <p />
397 <p />
398 <p />
399 <p />
400 <p />
401 End of Report
402 </body></html>
View Code
完成后会生成一个报表具体根据自己的观看
报告下载地址直达--------------------------->点击这里<------------------------------------------
三,AWR
01, AWR
首先要看俩个时间
Elapsed: 240.00 (mins) 表明采样时间是240分钟，任何数据都要通过这个时间来衡量，离开了这个采样时间，任何数据都毫无疑义
DB Time: 92,537.95 (mins) 表明用户操作花费的时候，包括cpu时间喝等待时间，也许有人会觉得奇怪，为什么在采样的240分钟过程中，用户操作时间竟然有92537分钟呢，远远超过了
采样时间，原因是awr报告是一个数据的集合，比如在一分钟之内，一个用户等待了30秒，那么10个用户就等待了300秒，对于cpu的话，一个cpu处理了30秒，16个cpu就是4800秒，这些时间都是以累积的方式记录在awr报告中的。
为了对数据库有个整体的认识，先看下面的性能指标
1. Buffer Nowait 说明 在从内存取数据的时候，没有经历等待的比例，期望值是100%
2. Buffer Hit 说明从内存取数据的时候，buffer的命中率的比例，期望值是100%，但100%并不代表性能就好，因为这只是一个比例而已，举个例子，执行一条 sql语句，# 执行计划是需要取10000个数据块，结果内存中还真有这10000个数据块，那么比例是100%，表面上看是性能最高的，还有一个执行计划是需要500 个数据块，内存中有250个，另外250个需要在物理磁盘中取，
这种情况下，buffer hit是50%，结果呢，第二个执行计划性能才是最高的，所以说100%并不代表性能最好
3. Library Hit 说明sql在Shared Pool的命中率，期望值是100%
4. Execute to Parse 说明解析sql和执行sql之间的比例，越高越好，说明一次解析，到处执行，如果parse多，execute少的话，还会出现负数，因为计算公式是100*（1-parse/execute）
5. Parse CPU to Parse Elapsd 说明在解析sql语句过程中，cpu占整个的解析时间比例，，期望值是100%，说明没有产生等待，需要说明的是，即使有硬解析，只要cpu没有出现性能问题，也是可以容忍的，比较硬解析也有它的好处的
6. Redo NoWait 说明在产生日志的时候，没有产生等待，期望值是100%
7. Soft Parse 说明软解析的比例，期望值是100%，有一点要说明的是，不要单方面的追求软解析的高比例，而去绑定变量，要看性能的瓶颈在哪里
8. Latch Hit 说明latch的命中率，期望值是100%，latch类似锁，是一种内存锁，但只会产生等待，不会产生阻塞，和lock还是有区别的，latch是在并发的情况下产生的
9. Non-Parse CPU 说明非解析cpu的比例，越高越好，用100减去这个比例，可以看出解析sql所花费的cpu，100-99.30=0.7，说明花费在解析sql上的cpu很少
- Time Model Statistics
可以看出，在整个sql执行时间（sql execute elapsed time）时间为5144秒中，解析时间（parse time elapsed）用了将近900秒秒，硬解析时间（hard parse elapsed time）用了同样也用了快900秒,硬解析时间占了整个解析时间的绝大部分，但解析时间是花的也特别多，所以可以判断出，sql的解析成为性能的瓶 颈，进一步推测，sql在获取数据的过程中倒是没有太多时间
- Top 5 Timed Events，从这里可以看出等待时间在前五位的是什么事件，基本上就可以判断出性能瓶颈在什么地方
Event | Waits | %Time -outs | Total Wait Time (s) | Avg wait | Waits /txn | % DB time |
acknowledge over PGA limit | 250,355 | 100 | 2,909 | 11.62ms | 3.35 | 38.13 |
PGA memory operation | 1,208,786 | 16 | 13.24us | 16.16 | 0.21 | |
Failed Logon Delay | 13 | 100 | 13 | 1000.08ms | 0.00 | 0.17 |
Pluggable Database file copy | 2,918 | 11 | 3.85ms | 0.04 | 0.15 | |
enq: JG - queue lock | 12 | 8 | 662.24ms | 0.00 | 0.10 | |
Disk file operations I/O | 49,900 | 8 | 157.65us | 0.67 | 0.10 | |
db file sequential read | 30,552 | 7 | 240.51us | 0.41 | 0.10 | |
log file sync | 2,498 | 7 | 2.73ms | 0.03 | 0.09 | |
local write wait | 1,825 | 5 | 2.84ms | 0.02 | 0.07 | |
enq: RO - fast object reuse | 1,450 | 4 | 2.93ms | 0.02 | 0.06 | |
control file parallel write | 742 | 2 | 2.72ms | 0.01 | 0.03 | |
enq: CR - block range reuse ckpt | 606 | 2 | 3.17ms | 0.01 | 0.03 | |
resmgr:cpu quantum | 68 | 2 | 24.59ms | 0.00 | 0.02 | |
reliable message | 2,432 | 1 | 609.97us | 0.03 | 0.02 | |
library cache lock | 22 | 1 | 63.11ms | 0.00 | 0.02 | |
latch: shared pool | 1,304 | 1 | 1.04ms | 0.02 | 0.02 | |
recovery area: computing obsolete files | 5 | 1 | 231.36ms | 0.00 | 0.02 | |
sort segment request | 1 | 100 | 1 | 999.28ms | 0.00 | 0.01 |
ADR block file read | 171 | 1 | 5.60ms | 0.00 | 0.01 | |
db file scattered read | 1,036 | 1 | 559.15us | 0.01 | 0.01 | |
direct path sync | 209 | 0 | 1.97ms | 0.00 | 0.01 | |
recovery area: computing backed up files | 5 | 0 | 73.53ms | 0.00 | 0.00 | |
DLM cross inst call completion | 80 | 0 | 3.71ms | 0.00 | 0.00 | |
undo segment extension | 47 | 98 | 0 | 4.59ms | 0.00 | 0.00 |
library cache: mutex X | 60 | 0 | 3.06ms | 0.00 | 0.00 | |
control file single write | 150 | 0 | 1.10ms | 0.00 | 0.00 | |
row cache mutex | 61 | 0 | 2.52ms | 0.00 | 0.00 | |
cursor: pin S wait on X | 19 | 0 | 7.30ms | 0.00 | 0.00 | |
rdbms ipc reply | 70 | 0 | 1.84ms | 0.00 | 0.00 | |
control file sequential read | 21,699 | 0 | 5.83us | 0.29 | 0.00 | |
resmgr:internal state change | 1 | 0 | 99.93ms | 0.00 | 0.00 | |
PX Deq: Slave Session Stats | 388 | 0 | 238.38us | 0.01 | 0.00 | |
log buffer space | 1 | 0 | 78.54ms | 0.00 | 0.00 | |
db file single write | 75 | 0 | 929.52us | 0.00 | 0.00 | |
library cache load lock | 17 | 0 | 3.74ms | 0.00 | 0.00 | |
recovery area: computing dropped files | 5 | 0 | 12.08ms | 0.00 | 0.00 | |
db file parallel read | 273 | 0 | 203.64us | 0.00 | 0.00 | |
row cache lock | 11 | 0 | 5.01ms | 0.00 | 0.00 | |
Data file init write | 88 | 0 | 526.43us | 0.00 | 0.00 | |
SQL*Net break/reset to client | 299 | 0 | 132.44us | 0.00 | 0.00 | |
log file switch (private strand flush incomplete) | 2 | 0 | 18.91ms | 0.00 | 0.00 | |
direct path write temp | 219 | 0 | 158.95us | 0.00 | 0.00 | |
PX Deq: Join ACK | 88 | 0 | 376.35us | 0.00 | 0.00 | |
resmgr:plan change | 10 | 0 | 3.22ms | 0.00 | 0.00 | |
library cache: bucket mutex X | 7 | 0 | 4.54ms | 0.00 | 0.00 | |
Compression analysis | 10,212 | 0 | 3.04us | 0.14 | 0.00 | |
oracle thread bootstrap | 4 | 0 | 6.92ms | 0.00 | 0.00 | |
latch free | 19 | 0 | 1.12ms | 0.00 | 0.00 | |
latch: enqueue hash chains | 2 | 0 | 10.64ms | 0.00 | 0.00 | |
write complete waits | 6 | 0 | 3.53ms | 0.00 | 0.00 | |
enq: TX - contention | 3 | 0 | 6.79ms | 0.00 | 0.00 | |
asynch descriptor resize | 1,230 | 100 | 0 | 7.39us | 0.02 | 0.00 |
row cache read | 8 | 0 | .96ms | 0.00 | 0.00 | |
PX Deq: Signal ACK EXT | 44 | 0 | 164.02us | 0.00 | 0.00 | |
buffer busy waits | 15 | 0 | 471.87us | 0.00 | 0.00 | |
enq: TC - contention | 8 | 0 | 618.25us | 0.00 | 0.00 | |
enq: PS - contention | 8 | 0 | 607.88us | 0.00 | 0.00 | |
kdic_do_merge | 816 | 0 | 4.81us | 0.01 | 0.00 | |
enq: CU - contention | 1 | 0 | 3.40ms | 0.00 | 0.00 | |
SQL*Net message to client | 4,903 | 0 | 647.15ns | 0.07 | 0.00 | |
CSS initialization | 1 | 0 | 3.07ms | 0.00 | 0.00 | |
cursor: pin S | 2 | 0 | 1.14ms | 0.00 | 0.00 | |
direct path write | 10 | 0 | 215.40us | 0.00 | 0.00 | |
latch: call allocation | 2 | 0 | 1.00ms | 0.00 | 0.00 | |
latch: cache buffers chains | 3 | 0 | 566.00us | 0.00 | 0.00 | |
latch: redo allocation | 3 | 0 | 345.00us | 0.00 | 0.00 | |
watchdog main loop | 350,487 | 1,051,183 | 2999.21ms | 4.69 | ||
jobq slave wait | 182,465 | 99 | 90,696 | 497.06ms | 2.44 | |
SQL*Net message from client | 4,902 | 87,039 | 17.76 s | 0.07 | ||
PL/SQL lock timer | 606 | 100 | 606 | 999.71ms | 0.01 | |
PX Deq: Execution Msg | 1,677 | 22 | 13.22ms | 0.02 | ||
PX Deq: Execute Reply | 220 | 10 | 45.98ms | 0.00 | ||
PX Deq: Table Q Normal | 44 | 0 | 2.63ms | 0.00 | ||
PX Deq: Parse Reply | 44 | 0 | 1.79ms | 0.00 | ||
PX Deq Credit: send blkd | 42 | 0 | 182.88us | 0.00 | ||
PX Deq: Msg Fragment | 8 | 0 | 490.13us | 0.00 | ||
PX Deq: Table Q Sample | 4 | 0 | 315.50us | 0.00 |
1. buffer busy waits 说明在获取数据的过程中，频繁的产生等待事件，很有可能产生了热点块，也就是说，很多会话都去读取同样的数据块，这一事件等待了5627394次，总共等待了5322924秒，平均等待时间为946毫秒，而且频率也是最高的，有95.9%，等待类别是并发
这里有一个概念：oracle操作的最小单位是块，当一个会话要修改这个块中的一条记录，会读取整个块，如果另一个会话要修改的数据也正好在这个块中，虽然这俩个
2. 会话修改的记录不一样，也会产生等待direct path write temp和direct path read temp 说明用到了临时表空间，那我们再看一下Tablespace IO Stats
各项指标都是非常高的，再根据上面的In-memory Sort是100%，没有产生磁盘排序，也就在排序的时候没有用到临时表空间，进一步推测，多个session，每个session执行的sql语句中多表关联，产生了很多中间数据，pga内存中放不下，
用到了临时表空间，也有可能是用到了lob字段，在用lob字段的时候，也会用到临时表
* 继续看SQL Statistics
根据buffer busy waits等待次数，时间，频率都是最高的，我们重点看逻辑读，物理读，和执行时间最长的sql，把排在前几位的拿出来优化
优化的原则为降低物理读，逻辑读，sql语句中的子操作执行次数尽量少，在看oracle估计出来的执行计划是看不出子操作的执行次数的，要看运行时的执行计划
* 有兴趣的话还可以看一下Segment Statistics
列出了用到的索引和表的使用情况，从这里也能看出索引和表的使用频率
* 也可以看一下Load Profile
里面列出了每秒，每个事务所产生的日志，逻辑读和物理读等指标
02 .AWR报告的分析
001 策略
因为AWR报告非常长，不可能从头到尾一字不漏的去看，要有选择的去看重点部分。最好能对照的来读，即和系统正常情况下的AWR报告对比，找差异。
AWR报告采用总分的形式，前面是系统的整体情况，后面是各个部分细节，一开始不要陷入细节，先分析系统的整体状况，对于后面的专题分析，要根据关注点的不同，采取跳跃式分析。
还要根据具体业务的不同，决定某种现象是否正常。
002 系统整体状况方面
1）Load Profile：分析系
了解系统整体负载状况，如每秒中的事务数/语句数，每秒/每事务物理读写次数(Physical Reads/Writes), 逻辑读写次数(Logical Reads/Writes)，SQL语句的解析(Parse)，特别是硬解析次数等。
2）Instance Efficiency Percentages：
各指标都应接近100%，除了：execute to parse (70%以上)和parse cpu to parse elapsed。如果不符合，基本可以确定系统存在性能问题；但是如果反过来，即都符合，也不能说明系统完全正常，还要看实际情况。
具体状况方面
1）Top 5 Timed Events：这里列出消耗时间最多的5个等待事件，每种等待说明，都表示一种原因，如：db file sequential read表示按索引访问出现等待，db file scattered reade表示全表扫描访问出现等待事件。
2）Top N SQL：根据时间消耗，内存消耗，物理I/O等排序，对相关SQL分析执行计划
3）如果是RAC环境，需要特别关注RAC Statistic中的相关指标
4）SGA PGA分析
5）分析表空间、数据文件I/O
003 WORKLOAD REPOSITORY report for
DB Time不包括Oracle后台进程消耗的时间。如果DB Time远远小于Elapsed时间，说明数据库比较空闲。
在79分钟里（其间收集了3次快照数据），数据库耗时11分钟，RDA数据中显示系统有8个逻辑CPU（4个物理CPU），平均每个CPU耗时1.4分钟，CPU利用率只有大约2%（1.4/79）。说明系统压力非常小。
可是对于批量系统，数据库的工作负载总是集中在一段时间内。如果快照周期不在这一段时间内，或者快照周期跨度太长而包含了大量的数据库空闲时间，所得出的分析结果是没有意义的。这也说明选择分析时间段很关键，要选择能够代表性能问题的时间段。
004 Report Summary
显示SGA中每个区域的大小（在AMM改变它们之后），可用来与初始参数值比较。
shared pool主要包括library cache和dictionary cache。library cache用来存储最近解析（或编译）后SQL、PL/SQL和Java classes等。library cache用来存储最近引用的数据字典。发生在library cache或dictionary cache的cache miss代价要比发生在buffer cache的代价高得多。因此shared pool的设置要确保最近使用的数据都能被cache。
005 Load Profile
显示数据库负载概况，将之与基线数据比较才具有更多的意义，如果每秒或每事务的负载变化不大，说明应用运行比较稳定。单个的报告数据只说明应用的负载情况，绝大多数据并没有一个所谓“正确”的值，然而Logons大于每秒1~2个、Hard parses大于每秒100、全部parses超过每秒300表明可能有争用问题。
Redo size：每秒/每事务产生的redo大小（单位字节），可标志数据库任务的繁重程序。
Logical reads：每秒/每事务逻辑读的块数
Block changes：每秒/每事务修改的块数
Physical reads：每秒/每事务物理读的块数
Physical writes：每秒/每事务物理写的块数
User calls：每秒/每事务用户call次数
Parses：SQL解析的次数
Hard parses：其中硬解析的次数，硬解析太多，说明SQL重用率不高。
Sorts：每秒/每事务的排序次数
Logons：每秒/每事务登录的次数
Executes：每秒/每事务SQL执行次数
Transactions：每秒事务数
Blocks changed per Read：表示逻辑读用于修改数据块的比例
Recursive Call：递归调用占所有操作的比率
Rollback per transaction：每事务的回滚率
Rows per Sort：每次排序的行数
注:
Oracle的硬解析和软解析
提到软解析(soft prase)和硬解析(hard prase)，就不能不说一下Oracle对sql的处理过程。当你发出一条sql语句交付Oracle，在执行和获取结果前，Oracle对此sql将进行几个步骤的处理过程：
1、语法检查(syntax check)
检查此sql的拼写是否语法。
2、语义检查(semantic check)
诸如检查sql语句中的访问对象是否存在及该用户是否具备相应的权限。
3、对sql语句进行解析(prase)
利用内部算法对sql进行解析，生成解析树(parse tree)及执行计划(execution plan)。
4、执行sql，返回结果(execute and return)
其中，软、硬解析就发生在第三个过程里。
Oracle利用内部的hash算法来取得该sql的hash值，然后在library cache里查找是否存在该hash值；
假设存在，则将此sql与cache中的进行比较；
假设“相同”，就将利用已有的解析树与执行计划，而省略了优化器的相关工作。这也就是软解析的过程。
诚然，如果上面的2个假设中任有一个不成立，那么优化器都将进行创建解析树、生成执行计划的动作。这个过程就叫硬解析。
创建解析树、生成执行计划对于sql的执行来说是开销昂贵的动作，所以，应当极力避免硬解析，尽量使用软解析。
006 Instance Efficiency Percentages (Target 100%)
本节包含了Oracle关键指标的内存命中率及其它数据库实例操作的效率。其中Buffer Hit Ratio 也称Cache Hit Ratio，Library Hit ratio也称Library Cache Hit ratio。同Load Profile一节相同，这一节也没有所谓“正确”的值，而只能根据应用的特点判断是否合适。在一个使用直接读执行大型并行查询的DSS环境，20%的Buffer Hit Ratio是可以接受的，而这个值对于一个OLTP系统是完全不能接受的。根据Oracle的经验，对于OLTPT系统，Buffer Hit Ratio理想应该在90%以上。
Buffer Nowait表示在内存获得数据的未等待比例。
buffer hit表示进程从内存中找到数据块的比率，监视这个值是否发生重大变化比这个值本身更重要。对于一般的OLTP系统，如果此值低于80%，应该给数据库分配更多的内存。
Redo NoWait表示在LOG缓冲区获得BUFFER的未等待比例。如果太低（可参考90%阀值），考虑增加LOG BUFFER。
library hit表示Oracle从Library Cache中检索到一个解析过的SQL或PL/SQL语句的比率，当应用程序调用SQL或存储过程时，Oracle检查Library Cache确定是否存在解析过的版本，如果存在，Oracle立即执行语句；如果不存在，Oracle解析此语句，并在Library Cache中为它分配共享SQL区。低的library hit ratio会导致过多的解析，增加CPU消耗，降低性能。如果library hit ratio低于90%，可能需要调大shared pool区。
Latch Hit：Latch是一种保护内存结构的锁，可以认为是SERVER进程获取访问内存数据结构的许可。要确保Latch Hit>99%，否则意味着Shared Pool latch争用，可能由于未共享的SQL，或者Library Cache太小，可使用绑定变更或调大Shared Pool解决。
Parse CPU to Parse Elapsd：解析实际运行时间/(解析实际运行时间+解析中等待资源时间)，越高越好。
Non-Parse CPU ：SQL实际运行时间/(SQL实际运行时间+SQL解析时间)，太低表示解析消耗时间过多。
Execute to Parse：是语句执行与分析的比例，如果要SQL重用率高，则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。
In-memory Sort：在内存中排序的比率，如果过低说明有大量的排序在临时表空间中进行。考虑调大PGA。
Soft Parse：软解析的百分比（softs/softs+hards），近似当作sql在共享区的命中率，太低则需要调整应用使用绑定变量。
007 hared Pool Statistics
Memory Usage %：对于一个已经运行一段时间的数据库来说，共享池内存使用率，应该稳定在75%-90%间，如果太小，说明Shared Pool有浪费，而如果高于90，说明共享池中有争用，内存不足。
SQL with executions>1：执行次数大于1的sql比率，如果此值太小，说明需要在应用中更多使用绑定变量，避免过多SQL解析。
Memory for SQL w/exec>1：执行次数大于1的SQL消耗内存的占比。
02. AWR快照的生成 [02. AWR kuàizhào de shēngchéng] 02. Generation of AWR snapshots
