Oracle數據庫的性能模型

在此特別感謝：

源地址：http://soft.chinabyte.com/database/334/11592834.shtml

提供 ↑
　Oracle數據庫的大恢復技巧介紹

　Java命令參數說明大全

　　最近一直在思考一個問題：如何爲一個數據庫創建性能模型？做爲一名DBA來講，咱們面臨的一個巨大挑戰是：如何保證數據庫的性能能夠知足快速變化的應用的需求，如何在數據量和訪問量持續增加的狀況下，保證應用的響應時間和數據庫的負載處在合理的水平下。咱們可能會常常面對如下的問題：某個SQL每秒要執行100次，響應時間是多少？某個應用發佈後，對數據庫的影響如何？因此，評估應用對數據庫所產生的影響，優化應用並預測風險，保證數據庫的可用性和穩定性，這是應用DBA真正有價值的地方。

　　響應時間爲中心：

　　若是要選擇一個評價系統優劣的性能指標，毫無疑問應該是響應時間。響應時間是客戶體驗的第一要素，全部的優化都應該爲下降響應時間而努力。對於數據庫系統也是如此，咱們優化系統，優化SQL，最終目標都是爲了下降響應時間，單位時間內能夠處理更多的請求。

　　數據庫時間模型：

　　響應時間通常分爲服務時間(Service time)和等待時間(Wait time)，服務時間指進程佔用CPU的時間，包括前臺進程(Server process)和後臺進程(Backgroud process)，咱們通常只關注前臺進程佔用的CPU time。等待時間包括不少類型，通常最多見的是IO等待和併發等待，IO等待包括sequential read，scattered read和log file sync等等，而併發等待主要是latch和enqueue。SQL execute elapsed time指用戶進程執行SQL的響應時間，包含CPU time和wait time。

　　如下是Oracle數據庫的時間模型：

 

　　在Oracle系統中，咱們能夠利用AWR或Statspack報告，看到數據庫的時間信息：

　　Statistic NameTime (s)% of DB Time

　　sql execute elapsed time3,062.1791.52

　　DB CPU2,842.0884.95

　　parse time elapsed25.870.77

　　PL/SQL execution elapsed time11.750.35

　　sequence load elapsed time7.550.23

　　hard parse elapsed time5.060.15

　　connection management call elapsed time3.130.09

　　hard parse (sharing criteria) elapsed time0.040.00

　　repeated bind elapsed time0.010.00

　　PL/SQL compilation elapsed time0.000.00

　　DB time3,345.74

　　background elapsed time204.91

　　background cpu time72.30

　　DB time是整個數據庫用戶進程消耗的總時間，是從第一項到第十項時間的總和(從sql execute elapsed time到PL/SQL compilation elapsed time)，可是咱們會發現這十項時間的總和比DB Time要大一些，這是由於部分時間信息有重疊的部分，好比SQL execute elapsed time就包括了很大一部分DB cpu的時間。而background elapsed time和background cpu time則是Oracle後臺進程消耗的時間和cpu time。

　　數據庫響應時間分析：

　　數據庫系統的響應時間由四個要素決定：CPU，IO，內存和網絡，其中CPU和IO是最重要的因素。與之相比，內存與網絡則簡單不少，由於一般狀況下，對於一個調優的系統來講，內存訪問的延遲時間很是小(100 ns如下，1 ms=1000000 ns)相比較CPU和IO幾乎能夠忽略。而網絡延遲則一般是一個常數，好比在一個數據中心的狀況下，網絡的延遲通常在3ms如下，若是存在多數據中心的狀況，網絡延遲可能會超過20ms，因此對於一個分佈式系統來講，網絡延遲是必需要考慮的問題。

　　在這裏，咱們不考慮分佈式系統，而且忽略內存的訪問延遲，重點分析CPU和IO，咱們看如下數據庫的AWR片斷：

 

　　咱們看到這個系統中DB CPU佔整個DB time的87.21%，User I/O佔整個DB time的9.12%，commit相關的IO等待佔2.35%(主要是log file sync)，CPU和IO佔用了整個DB time的96.68%。因爲DB CPU所佔的比例很高，因此這個數據庫系統是CPU intensive類型，這裏的DB CPU主要是執行SQL的服務時間。

　　咱們再看另外的一個數據庫的AWR片斷：

 

　　咱們看到，Commit和User I/O佔DB time的81.46%，而DB CPU只佔13.82%，因此這個數據庫系統是IO instensive類型的。

　　Physical read

　　Physical read是指Oracle在buffer cache中沒有找到相應的block，須要從IO子系統讀取相應的block的過程，對應的IO稱爲物理IO，物理讀數量表明物理IO讀取的block數量。由於通常IO子系統都是慢速的磁盤，因此物理IO對總體響應時間的影響很是大，若是發生大量的物理IO，整個系統的響應時間會變得不好。系統的IO子系統多是文件系統，裸設備或者ASM，底層硬件多是SAN存儲，NAS存儲或者普通SAS磁盤等等。爲了提升響應時間，一般在物理磁盤與Oracle之間增長cache層，對於Oracle來講，物理IO並不必定是真正訪問磁盤，極可能是訪問文件系統cache，存儲的cache等等。

　　無論IO subsystem是什麼，Oracle只關心物理IO的響應時間。經過AWR報告，咱們能夠看到物理IO的響應時間：

 

　　db file sequential read(單塊讀，隨機IO)的平均響應時間爲3ms，db file scattered read(多塊讀，連續IO)的平均響應時間是4ms，logfile file sync的平均響應時間是3ms，前二者的Wait class是User I/O，表明用戶進程讀操做的響應時間，logfile sync的wait class是Commit，表明lgwr進程寫redo的響應時間，由於用戶commit必須完成log file sync的操做，因此它也會直接影響用戶進程寫操做的響應時間。

　　關於物理IO的響應時間，咱們有一個經驗值。對於Sequential read和Scattered read，咱們認爲小於10ms屬於正常狀態，而大於10ms則認爲IO subsystem的響應延遲過大。因此咱們在衡量存儲系統的性能時，只有響應時間在10ms如下的IO咱們認爲是有效的。這裏有一個有趣的現象，就是sequential read和scattered read的響應時間幾乎相差無幾，也就是說隨機IO讀取8K數據和連續IO讀取128K數據，響應時間差異很小，這是由磁盤的機械特性形成的，延遲時間=尋道時間+

　　對於log file sync的響應時間，由於用戶commit必須完成log file sync，因此整個系統的寫操做的響應時間都取決於它的響應時間，並且從整個數據庫系統的角度去看，log file sync幾乎是串行的，因此這個響應時間對寫操做影響很是大，咱們的經驗值是必須保證在5ms如下，若是超過5ms整個系統的寫操做都會受到嚴重的影響。

　　Logical read

　　Logical read是Oracle從buffer cache中讀取block的過程，對應的IO稱爲邏輯IO，邏輯讀數量表明邏輯IO讀取的block數量。由於Oracle必須首先將block讀入buffer cache中(direct path read除外)，因此邏輯讀數量包含了物理讀數量。對於一個SQL來講，邏輯讀數量是衡量其性能的標準，而不是物理讀。雖然物理IO的響應延遲比邏輯IO大不少，可是物理讀數量會隨着執行次數而變化(頻繁讀取致使block被緩存在buffer cache中)。對於一個系統也是如此，邏輯讀應該是數據庫性能評估模型的核心，咱們須要創建邏輯讀與響應時間的對應關係。

　　每一個邏輯讀的響應時間是多少，這是一個巨大的挑戰。由於每一個邏輯讀背後隱藏了不少動做，可能包括物理讀，等待事件，CPU time等等。我對不少數據庫的AWR報告作了分析，指望根據經驗值創建一個簡化的模型。咱們假設一個數據庫若是是充分調優的，除CPU time和IO之外的等待時間應該儘量少(應小於DB time 10%)。在這個前提下，咱們只關心CPU time和IO的影響，並將系統分爲三類：CPU密集型，IO密集型和混合型：

　　1.IO密集型

　　User IO 85%

　　DB CPU 5%

　　每邏輯讀響應時間0.1-0.5ms

　　2.CPU密集型

　　DB CPU 85%

　　User IO 10%

　　每邏輯讀響應時間小於0.01ms

　　3.混合型

　　User I/O 60%

　　DB CPU 20%

　　每邏輯讀響應時間0.05-0.1ms

　　以上數據是根據不少個典型數據庫的AWR報告計算出來的經驗值，計算公式很簡單：DB time/邏輯讀=每邏輯讀響應時間。由於並無考慮硬件和OS上的差別，因此這個數值並非特別準確，但咱們仍是能夠發現一些規律：隨着IO所佔比例從10%增長到85%，響應時間也從小於0.01ms到0.5ms。

　　預測系統瓶頸

　　對於數據庫來講，IO子系統對性能影響很是大，必須保證在必定的IO的壓力下，響應延遲控制在合理的範圍內(前面說的10ms和5ms)。由於每塊磁盤能夠承受的IOPS是基本肯定的，好比15K的SAS磁盤，在響應延遲不超過10ms的前提下，能夠提供150個IOPS，若是不考慮cache的影響，整個存儲子系統的IOPS是比較容易計算的。咱們能夠在系統上線前，進行大量充分的測試，創建存儲IOPS與響應延遲的模型，這樣咱們就能夠預測出性能出現拐點的風險，提早作出擴容的判斷。在AWR報告中，咱們能夠獲得每秒的物理IO的數量和響應時間，能夠方便的實現性能監控和趨勢預警。

　　評估CPU的容量瓶頸相對簡單，Oracle中CPU time的計算是每一個CPU耗費時間的總和，若是有16顆(核)CPU，1個小時理論上能夠提供3600×16=57600s CPU time，不超過57600s CPU time咱們能夠認爲不會在CPU上排隊，系統不會出現CPU瓶頸。可是須要注意的是，除了用戶進程使用CPU之外，操做系統也須要佔用CPU資源，用來管理內存和進程調度等。咱們在OS上看到的CPU使用率中的sys部分就是系統佔用的CPU資源，因此應該考慮至少保留10-20%的CPU資源給OS使用。

　　併發訪問對數據庫的影響

　　Oracle是一個Disk-based database，設計的出發點就是大部分數據在外部存儲中，而只有小部分數據被cache在buffer中，它既不一樣於Memcache這類KV cache，也不一樣於timesten這類In-memory database。因此，就算是全部的數據均可以被cache在buffer中，在高併發訪問的狀況下，也可能會出現大量的latch等待，最多見的狀況就是cache buffer chain。當大量併發訪問同一塊數據時，就極可能會出現cache buffer chain的latch爭用，也就是咱們常說的「熱點」。

　　須要注意的是：Oracle中的latch等待分爲spin和sleep兩個部分，spin消耗cpu time，而sleep則是等待時間。因此大量的latch等待不只僅會產生大量的等待時間，並且會消耗大量的CPU time。

　　Oracle是一個爲併發操做而設計的數據庫，大量的併發讀寫請求，可能會帶來額外的性能消耗。好比讀取一部分頻繁修改的數據，Oracle爲了保證一致性讀的須要，會利用undo信息構造產生大量CR block，同時會產生大量的邏輯讀，這樣會消耗額外的CPU和響應時間。

　　存儲也可能存在熱點的問題，須要前期對存儲系統充分的優化，常見的手段是利用RAID技術，將數據分散在不一樣的磁盤上，防止出現「熱點」盤。Oracle ASM提供了Rebalance的功能，容許DBA將存儲中的的數據從新分佈，達到消除熱點的目的。

　　總之，Oracle是一個能夠提供大量併發讀寫訪問的數據庫系統，可是在不少地方，Oracle又不得采用一些串行的控制手段，好比latch，enqueue和mutex，咱們要作的就是儘可能下降這些串行控制對數據庫總體性能的影響。

　　數據庫優化原則

　　基於響應時間的Oracle優化原則：儘可能減小等待時間(Wait time)，提升服務時間(Service time)。這也是基於Oracle等待事件的分析方法的基本原則：儘可能消除各類等待事件對系統的影響，從而提升系統性能和響應時間。

　　若是數據庫系統除了CPU和IO之外的等待時間超過DB time的5%以上的話，可能存在某些性能問題，須要DBA採用等待事件的分析方法，對系統或應用進行優化。

原文出自【比特網】，轉載請保留原文連接：http://soft.chinabyte.com/database/334/11592834.shtml