Oracle中的AWR，全稱為Automatic Workload Repository，自動負載信息庫。 

AWR是DBA了解其運行狀態(tài)的重要工具之一，根據(jù)AWR報告可以對oracle數(shù)據(jù)庫性能整體了解并針對性優(yōu)化，此文章主要是介紹AWR相關部分的內容。

成都創(chuàng)新互聯(lián)2013年至今，是專業(yè)互聯(lián)網(wǎng)技術服務公司，擁有項目成都做網(wǎng)站、成都網(wǎng)站設計網(wǎng)站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元鯉城做網(wǎng)站,已為上家服務,為鯉城各地企業(yè)和個人服務,聯(lián)系電話:13518219792

DB Name         DB Id    Instance     Inst Num Startup Time    Release     RAC

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

                                             1 16-Jan-17 09:27 11.2.0.4.0  NO

Host Name        Platform                         CPUs Cores Sockets Memory(GB)

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

                 Linux x86 64-bit                    8     8       2       7.81

              Snap Id      Snap Time      Sessions Curs/Sess

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

Begin Snap:     10848 14-Mar-17 09:00:51        66       1.4

  End Snap:     10849 14-Mar-17 10:00:55        66       1.5

   Elapsed:               60.07 (mins)

   DB Time:                0.93 (mins)

Sessions

采集性能信息時，oracle 實例鏈接的會話數(shù)，有助于判斷DB的類

Cursors/Session

單個會話平均打開的游標數(shù)

Elapsed

DB實際使用時間

DB Time

數(shù)據(jù)庫操作花費的時間，包括CPU和Wait Event time，DB Time越高數(shù)據(jù)庫，數(shù)據(jù)庫負載越高。

通過DB Time/Elapsed 比值判斷數(shù)據(jù)庫的繁忙程度，比值越高，數(shù)據(jù)庫越繁忙。

DB Time = CPU time + Wait time（不包括后臺進程及空閑等待）

對應V$SESSION 中的elapsed_time

Load Profile                    Per Second   Per Transaction  Per Exec  Per Call

~~~~~~~~~~~~~~~            ---------------   --------------- --------- ---------

             DB Time(s):               0.0               0.0      0.00      0.00

              DB CPU(s):               0.0               0.0      0.00      0.00

      Redo size (bytes):           1,343.6           3,388.8

  Logical read (blocks):             394.1             993.9

          Block changes:               5.4              13.6

 Physical read (blocks):               0.4               1.1

Physical write (blocks):               0.6               1.4

       Read IO requests:               0.4               1.1

      Write IO requests:               0.4               1.1

           Read IO (MB):               0.0               0.0

          Write IO (MB):               0.0               0.0

             User calls:              64.8             163.4

           Parses (SQL):              21.0              52.9

      Hard parses (SQL):               0.0               0.1

     SQL Work Area (MB):               0.2               0.5

                 Logons:               0.1               0.2

         Executes (SQL):              22.2              55.9

              Rollbacks:               0.0               0.0

           Transactions:               0.4

DB Time    DB CPU

DB Time 3.3s DB CPU 1.4s   Wait Event 3.3-1.4=1.9s, DB CPU占DB Time的比重為1.4/3.3=42%

可以看出此DB系統(tǒng)的非CPU等待占比比較大

DB CPU占比42.55%

db file sequential read/db file scattered read//libary cache:mutex X/latch:shared pool為CPU等待的TOP 4 wait event

（DB Time > DB CPU + FG Wait event   DB Time 會計算在CPU繁忙時的等待CPU的隊列時間）

繼續(xù)分析

redo size   日志的產(chǎn)生量

Logical reads  邏輯讀，單位是塊

良好的OLTP logical reads/ Executes 在50左右

Block Changes

每秒、事務改變的數(shù)據(jù)塊

Physical reads

物理讀

User Calls

每秒(每個事務)用戶調用次數(shù)。User calls/Executes基本上代表了每個語句的請求次數(shù)，Executes越接近User calls越好

Pasre

解析次數(shù)，不包括快速軟解析（MOS上說執(zhí)行3次的SQL語句會把游標緩存到PGA，這個游標一直開著，當再有相同的SQL執(zhí)行時，則跳過解析的所有過程直接去取執(zhí)行計劃）

軟解析過多說明應用程序的效率不高

Hard Parse

硬解析的次數(shù)，此指標過高說明綁定變量沒有做好

Sorts

排序次數(shù)

W/A MB processed 

單位MB  W/A workarea  workarea中處理的數(shù)據(jù)數(shù)量  結合 In-memory Sort%， sorts (disk) PGA Aggr一起看   

Logon

登入數(shù)據(jù)庫的次數(shù)

Executes

執(zhí)行次數(shù)

Rollbacks

回滾次數(shù)

Transactions

事務數(shù)

Instance Efficiency Percentages (Target 100%)

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

            Buffer Nowait %:  100.00       Redo NoWait %:  100.00

            Buffer  Hit   %:  100.00    In-memory Sort %:  100.00

            Library Hit   %:   99.30        Soft Parse %:   99.79

         Execute to Parse %:    5.27         Latch Hit %:  100.00

Parse CPU to Parse Elapsd %:   78.31     % Non-Parse CPU:   94.25

此模塊記錄oracle instance memory的使用信息，目標為100%，針對OLTP系統(tǒng)，此模塊信息比較重要，對于OLAP系統(tǒng)，意義不大。

Buffer Nowait%

非等待方式獲取數(shù)據(jù)塊的百分比

這個值偏小，說明發(fā)生SQL訪問數(shù)據(jù)塊時數(shù)據(jù)塊正在被別的會話讀入內存，需要等待這個操作完成。發(fā)生這樣的事情通常就是某些數(shù)據(jù)塊變成了熱塊。

 

Buffer Nowait<95%說明，有可能是有熱塊(查找x$bh的 tch和v$latch_children的cache buffers chains)。

Redo Nowait

非等待獲取redo數(shù)據(jù)

Buffer Hit%

數(shù)據(jù)緩存命中率

In-memory Sort%

數(shù)據(jù)排除操作在內存中的百分比

Library Hit%

共享池中SQL解析的命中率

（相關參數(shù)SHARED_POOL_SIZE\BINGD VALUE\CURSOR_SHARING）

Soft Parse %

軟解析占解析的比率  value偏低表示DB中多數(shù)SQL沒有被重用  <95%考慮綁定變量

Latch Hit%

Latch的命中率

其值低是因為shared_pool_size過大或沒有使用綁定變量導致硬解析過多。要確保>99%，否則存在嚴重的性能問題，比如綁定等會影響該參數(shù)。

Parse CPU to Parse Elapsd%

解析總時間中消耗CPU的時間百分比。即:100*(parse time cpu / parse time elapsed)

解析實際運行事件/(解析實際運行時間+解析中等待資源時間)，越高越好。

%Non-Parse CPU

CPU非分析時間在整個CPU時間的百分比。

 Shared Pool Statistics        Begin    End

~~~~~~~~~~~~~~~~~~~~~~~~~~~~  ------  ------

             Memory Usage %:   87.44   87.82

    % SQL with executions>1:   98.06   97.25

  % Memory for SQL w/exec>1:   92.56   92.46

Memory Usage %

 

共享池內存使用率。

應該穩(wěn)定在70%-90%間，太小浪費內存，太大則內存不足。

 

% SQL with executions>1

 

執(zhí)行次數(shù)大于1的SQL比率。

若太小可能是沒有使用綁定變量。

 

% Memory for SQL w/exec>1

 

執(zhí)行次數(shù)大于1的SQL消耗內存/所有SQL消耗的內存(即memory for sql with execution > 1)。 

本文題目：淺談ORACLEAWRsingleinstance一
鏈接地址：http://chinadenli.net/article8/goieop.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設計、網(wǎng)站設計公司、網(wǎng)頁設計公司、響應式網(wǎng)站、網(wǎng)站改版、Google

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)