淺談ORACLE AWR single instance 一

來源:互聯網
上載者:User

標籤:oracle   memory   single   

Oracle中的AWR,全稱為Automatic Workload Repository,自動負載資訊庫。 

AWR是DBA瞭解其運行狀態的重要工具之一,根據AWR報告可以對oracle資料庫效能整體瞭解並針對性最佳化,此文章主要是介紹AWR相關部分的內容。

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 執行個體連結的會話數,有助於判斷DB的類

Cursors/Session

單個會話平均開啟的遊標數

Elapsed

DB實際使用時間

DB Time

資料庫操作花費的時間,包括CPU和Wait Event time,DB Time越高資料庫,資料庫負載越高。

通過DB Time/Elapsed 比值判斷資料庫的繁忙程度,比值越高,資料庫越繁忙。

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系統的非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的隊列時間)

繼續分析

redo size   日誌的產生量

Logical reads  邏輯讀,單位是塊

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

Block Changes

每秒、事務改變的資料區塊

Physical reads

物理讀

User Calls

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

Pasre

解析次數,不包括快速軟解析(MOS上說執行3次的SQL語句會把遊標緩衝到PGA,這個遊標一直開著,當再有相同的SQL執行時,則跳過解析的所有過程直接去取執行計畫)

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

Hard Parse

硬解析的次數,此指標過高說明綁定變數沒有做好

Sorts

排序次數

W/A MB processed 

單位MB  W/A workarea  workarea中處理的資料數量  結合 In-memory Sort%, sorts (disk) PGA Aggr一起看   

Logon

登入資料庫的次數

Executes

執行次數

Rollbacks

復原次數

Transactions

事務數

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系統,此模組資訊比較重要,對於OLAP系統,意義不大。

Buffer Nowait%

非等待方式擷取資料區塊的百分比

這個值偏小,說明發生SQL訪問資料區塊時資料區塊正在被別的會話讀入記憶體,需要等待這個操作完成。發生這樣的事情通常就是某些資料區塊變成了熱塊。

 

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

Redo Nowait

非等待擷取redo資料

Buffer Hit%

資料快取命中率

In-memory Sort%

資料排除操作在記憶體中的百分比

Library Hit%

共用池中SQL解析的命中率

(相關參數SHARED_POOL_SIZE\BINGD VALUE\CURSOR_SHARING)

Soft Parse %

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

Latch Hit%

Latch的命中率

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

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 %

 

共用池記憶體使用量率。

應該穩定在70%-90%間,太小浪費記憶體,太大則記憶體不足。

 

% SQL with executions>1

 

執行次數大於1的SQL比率。

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

 

% Memory for SQL w/exec>1

 

執行次數大於1的SQL消耗記憶體/所有SQL消耗的記憶體(即memory for sql with execution > 1)。 


淺談ORACLE AWR single instance 一

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.