一, 前言
- 當我們把一條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>
完成后會生成一個報表具體根據自己的觀看
報告下載地址直達--------------------------->點擊這里<------------------------------------------
三,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
在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消耗內存的占比。
參考文章: https://blog.csdn.net/haojiubujian920416/article/details/81511030
