Oracle數(shù)據(jù)庫性能模型

最近一宜在思考一個(gè)問題：如何為一個(gè)數(shù)據(jù)庫建立性能模型？作為一名DBA來說，我們面臨的一個(gè)巨大挑戰(zhàn)是：如何保證數(shù)據(jù)庫的性能可以滿足快速變化的應(yīng)用的需求，如何在數(shù)據(jù)量和訪問量持續(xù)增長的情況下，保證應(yīng)用的響應(yīng)時(shí)間和數(shù)據(jù)庫的負(fù)載處在合理的水平下。我們可能會(huì)經(jīng)常面對(duì)以下的問題：某個(gè)SQL每秒要執(zhí)行100次，響應(yīng)時(shí)間是多少？某個(gè)應(yīng)用發(fā)布后，對(duì)數(shù)據(jù)庫的影響如何？所以，評(píng)估應(yīng)用對(duì)數(shù)據(jù)庫所產(chǎn)生的影響，優(yōu)化應(yīng)用并預(yù)測風(fēng)險(xiǎn)，保證數(shù)據(jù)庫的可用性和穩(wěn)定性，這是應(yīng)用DBA真正有價(jià)值的地方。響應(yīng)時(shí)間為中心：如果要選擇一個(gè)評(píng)價(jià)系統(tǒng)優(yōu)劣的性能指標(biāo)，亳無疑問應(yīng)該是響應(yīng)時(shí)間。響應(yīng)時(shí)間是客戶體驗(yàn)的第一要素，所有的優(yōu)化都應(yīng)該為降低響應(yīng)時(shí)間而努力。對(duì)于數(shù)據(jù)庫系統(tǒng)也是如此，我們優(yōu)化系統(tǒng)，優(yōu)化SQL,最終目標(biāo)都是為了降低響應(yīng)時(shí)間，單位時(shí)間內(nèi)可以處理更多的請(qǐng)求。數(shù)據(jù)庫時(shí)間模型：響應(yīng)時(shí)間一般分為服務(wù)時(shí)間(Servicetime)和等待時(shí)間(Waittime),服務(wù)時(shí)間指進(jìn)程占用CPU的時(shí)間，包括前臺(tái)進(jìn)程(Serverprocess)和后臺(tái)進(jìn)程(Backgroudprocess),我們一般只關(guān)注前臺(tái)進(jìn)程占用的CPLltimeo等待時(shí)間包括很多類型，一般最常見的是10等待和并發(fā)等待，10等待包括sequentialread,scatteredread和logfilesync等等，而并發(fā)等待主要是latch和enqueueoSQLexecuteelapsedtime指用戶進(jìn)程執(zhí)行SQL的響應(yīng)時(shí)問，包含CPUtime和waittime。以下是Oracle數(shù)據(jù)庫的時(shí)間模型:ServicetimeWaittimeBackgroupprocessServerprocessIOwailConcurrencyDBCPULatchLockSequentialread

Scatteredread

LogfiBesyncDBCPULatchLock在Oracle系統(tǒng)中，我們可以利用AWR或Statspack報(bào)告，看到數(shù)據(jù)庫的時(shí)間信息:sqlexecutee1apsodtime3.062.1791.52DBCPU2.842.0884.95parsetimeelapsed25.870.77PL/SQLexecutione1apsedtimo11.750.35sequenceloade1apsedtime7.550.23hardparsee1apsedtime5.060.15connectionmanagementcal1e1apsedtime3.130.09hardparse(sharingcriteria)elapsedtime0.010.00repeatedbindelapsedtime0.010.00PL/SQI.pilationelapsedtime0.000.00DBtime3?345?74backgrounde1apsedtime201.91backgroundcputime72.30DBtime是整個(gè)數(shù)據(jù)庫用戶進(jìn)程消耗的總時(shí)間，是從第一項(xiàng)到第十項(xiàng)時(shí)間的總和(從sqlexecuteelapsedtime到PL/SQLpilationelapsedtime),但是我們會(huì)發(fā)現(xiàn)這十項(xiàng)時(shí)間的總和比DBTime要大一些，這是因?yàn)椴糠謺r(shí)間信息有重疊的部分，比如SQLexecuteelapsedtime就包括了很大一部分DBcpu的時(shí)間。而backgroundelapsedtime和backgroundcputime則是Oracle后臺(tái)進(jìn)程消耗的時(shí)間和cputime。數(shù)據(jù)庫響應(yīng)時(shí)間分析：數(shù)據(jù)庫系統(tǒng)的響應(yīng)時(shí)間由四個(gè)要素決定：CPU,10,內(nèi)存和網(wǎng)絡(luò)，其中CPU和10長最重要的因素。與之相比，內(nèi)存與網(wǎng)絡(luò)則簡單很多，因?yàn)橥ǔＧ闆r下，對(duì)于一個(gè)調(diào)優(yōu)的系統(tǒng)來說，內(nèi)存訪問的延遲時(shí)間非常?。?00ns以下，1ms二1000000ns）相比較CPU和10幾乎可以忽略。而網(wǎng)絡(luò)延遲則通常是一個(gè)常數(shù)，比如在一個(gè)數(shù)據(jù)中心的情況下，網(wǎng)絡(luò)的延遲一般在3ms以下，如果存在多數(shù)據(jù)中心的情況，網(wǎng)絡(luò)延遲可能會(huì)超過20ms,所以對(duì)于一個(gè)分布式系統(tǒng)來說，網(wǎng)絡(luò)延遲是必須要考慮的問題。在這里，我們不考慮分布式系統(tǒng)，并且忽略內(nèi)存的訪問延遲，重點(diǎn)分析CPU和10,我們看以下數(shù)據(jù)庫的AWR片段：WaitClassWaitsQ4)TimG-outsTotalWaitTime(s)Avgwait(ms)忱DBtimeDBCPU3,35187.21UserI/O257,450035019.12Commit127,672□9012.35Cluster53,77001000.27Concurrency25z6527900.24SystemI/O3.,6230620.15Network2.-069,0010500.14Application6790570.13Other20z82878400.10Configuration23530210.06我們看到這個(gè)系統(tǒng)中DBCPU占整個(gè)DBtime的87.21%,UserI/O占整個(gè)DBtime的9.12%,mit相關(guān)的10等待占2.35%（主要是logfilesync）.CPU和10占用了整個(gè)DBtime的96.68%。由于DBCPU所占的比例很高，所以這個(gè)數(shù)據(jù)庫系統(tǒng)是CPUintensive類型，這里的DBCPU主要是執(zhí)行SQL的服務(wù)時(shí)間。我們?cè)倏戳硗獾囊粋€(gè)數(shù)據(jù)庫的AWR片段:

WaitClassWaits%Time-outsTotalWaitTime(s)Avgwait(ms)%DBtimeCommit817r47005f232667.49UserI/O238,8500lz083513.97DBCPUlz07113.82Configuration4,1501403975.20Concurrency42,626273110.40SystemI/O23J420600.07Network1,838,0620200.03Application1250020.00Other2,02682000.00我們看到，mit和UserI/O占DBtime的81.46%,而DBCPU只占13.82%,所以這個(gè)數(shù)據(jù)庫系統(tǒng)是IOinstensive類型的。PhysicalreadPhysicalread是指Oracle在buffercache中沒有找到相應(yīng)的block,需要從10子系統(tǒng)讀取相應(yīng)的block的過程，對(duì)應(yīng)的10稱為物理10,物理讀數(shù)量代表物理10讀取的block數(shù)量。因?yàn)橐话?0子系統(tǒng)都是慢速的磁盤，所以物理10對(duì)整體響應(yīng)時(shí)間的影響非常大，如果發(fā)生大量的物理10,整個(gè)系統(tǒng)的響應(yīng)時(shí)間會(huì)變得很差。系統(tǒng)的10子系統(tǒng)可能是文件系統(tǒng),裸設(shè)備或者ASM,底層硬件可能是SAN存儲(chǔ)，NAS存儲(chǔ)或者普通SAS磁盤等等。為了提高響應(yīng)時(shí)間，通常在物理磁盤與0racle之間增加cache層，對(duì)于0racle來說，物理10并不一定是真正訪問磁盤，很可能是訪問文件系統(tǒng)cache,存儲(chǔ)的cache等等。不管10subsystem是什么，Orscle只關(guān)心物理10的響應(yīng)時(shí)間。通過AWR報(bào)告，我們可以看到物理10的響應(yīng)時(shí)間：EventWaitsQ^TimG-outsTotalWaitTime(s)Avgwait(ms)Waits/txn%DBtimedbfilesequentialread4z215z803Ollr202329.6553.06dbfilescattArpdread320,14801,43442.206.79directpathread683..70701,23924.705.87SQL^N^tmoredatafromclient145,678079151.003.75logfilesync145,656043931.002.08dbfilesequentialread（單塊讀,隨機(jī)IO）的平均響應(yīng)時(shí)間為3ms,dbfilescatteredread（多塊讀，連續(xù)IO）的平均響應(yīng)時(shí)間是4ms,logfilefilesync的平均響應(yīng)時(shí)間是3ms,前兩者的Waitclass是UserI/O,代表用戶進(jìn)程讀操作的響應(yīng)時(shí)間，logfilesync的waitclass是mit,代表lgwr進(jìn)程寫redo的響應(yīng)時(shí)間，因?yàn)橛脩鬽it必須完成logfilesync的操作，所以它也會(huì)直接影響用戶進(jìn)程寫操作的響應(yīng)時(shí)間。關(guān)于物理10的響應(yīng)時(shí)間,我們有一個(gè)經(jīng)驗(yàn)值。對(duì)于Sequentialread和Scatteredread,我們認(rèn)為小于10ms屬于正?！鰻顟B(tài)，而大于10ms則認(rèn)為10subsystem的響應(yīng)延遲過大。所以我們?cè)诤饬看鎯?chǔ)系統(tǒng)的性能時(shí)，只有響應(yīng)時(shí)間在10ms以下的10我們認(rèn)為是有效的。這里有一個(gè)有趣的現(xiàn)象，就是sequentialread和scatteredread的響應(yīng)時(shí)間幾乎相差無幾，也就是說隨機(jī)10讀取8K數(shù)據(jù)和連續(xù)10讀取128K數(shù)據(jù)，響應(yīng)時(shí)間差別很小，這是由磁盤的機(jī)械特性造成的，延遲時(shí)間二尋道時(shí)間+對(duì)于logf訂esync的響應(yīng)時(shí)間,因?yàn)橛脩鬽it必須完成logfilesync,所以整個(gè)系統(tǒng)的寫操作的響應(yīng)時(shí)間都取決于它的響應(yīng)時(shí)間，而且從整個(gè)數(shù)據(jù)庫系統(tǒng)的角度去看，logfilesync幾乎是串行的，所以這個(gè)響應(yīng)時(shí)間對(duì)寫操作影響非常大，我們的經(jīng)驗(yàn)值是必須保證在5ms以下，如果超過5ms整個(gè)系統(tǒng)的寫操作都會(huì)受到嚴(yán)重的影響。LogicalreadLogicalread是Orac1e從buffercache中讀取block的過程，對(duì)應(yīng)的10稱為邏輯10,邏輯讀數(shù)量代表邏輯10讀取的block數(shù)量。因?yàn)镺racle必須首先將block讀入buffercache中（directpathread除外），所以邏輯讀數(shù)量包含了物理讀數(shù)量。對(duì)于一個(gè)SQL來說，邏輯讀數(shù)量是衡量其性能的標(biāo)準(zhǔn)，而不是物理讀。雖然物理10的響應(yīng)延遲比邏輯10大很多，但是物理讀數(shù)量會(huì)隨著執(zhí)行次數(shù)而變化（頻繁讀取導(dǎo)致block被緩存在buffercache中）。對(duì)于一個(gè)系統(tǒng)也是如此，邏輯讀應(yīng)該是數(shù)據(jù)庫性能評(píng)估模型的核心，我們需要建立邏輯讀與響應(yīng)時(shí)間的對(duì)應(yīng)關(guān)系。每個(gè)邏輯讀的響應(yīng)時(shí)間是多少，這是一個(gè)巨大的挑戰(zhàn)。因?yàn)槊總€(gè)邏輯讀背后隱藏了很多動(dòng)作，可能包括物理讀，等待事件，CPUtime等等。我對(duì)很多數(shù)據(jù)庫的AWR報(bào)告做了分析,期望根據(jù)經(jīng)驗(yàn)值建立一個(gè)簡化的模型。我們假設(shè)一個(gè)數(shù)據(jù)庫如果是充分調(diào)優(yōu)的，除CPUtime和10以外的等待時(shí)間應(yīng)該盡可能少（應(yīng)小于DBtime10%）。在這個(gè)前提下，我們只關(guān)心CPUtime和10的影響，并將系統(tǒng)分為三類：CPU密集型，10密集型和混合型：10密集型User10 85%DBCPU 5%每邏輯讀響應(yīng)時(shí)間0.1-0.5msCPU密集型DBCPU 85%UserIO 10%每邏輯讀響應(yīng)時(shí)間小于0.01ms混合型UserI/O 60%DBCPU 20%每邏輯讀響應(yīng)時(shí)間0.05-0.1ms以上數(shù)據(jù)是根據(jù)很多個(gè)典型數(shù)據(jù)庫的AWR報(bào)告計(jì)算出來的經(jīng)驗(yàn)值，計(jì)算公式很簡單：DBtime/邏輯讀二每邏輯讀響應(yīng)時(shí)間。因?yàn)椴]有考慮硬件和OS上的差異，所以這個(gè)數(shù)值并不是特別準(zhǔn)確，但我們還是可以發(fā)現(xiàn)一些規(guī)律：隨著10所占比例從10%增加到85%,響應(yīng)時(shí)間也從小于0.01ms到0.5mso預(yù)測系統(tǒng)瓶頸對(duì)于數(shù)據(jù)庫來說，10子系統(tǒng)對(duì)性能影響非常大，必須保證在一定的10的壓力下，響應(yīng)延遲控制在合理的X圍內(nèi)（前面說的10ms和5ms）。因?yàn)槊繅K磁盤可以承受的IOPS是基本確定的，比如15K的SAS磁盤，在響應(yīng)延遲不超過10ms的前提下，可以提供150個(gè)IOPS,如果不考慮cache的影響，整個(gè)存儲(chǔ)子系統(tǒng)的IOPS是比較容易計(jì)算的。我們可以在系統(tǒng)上線前，進(jìn)行大量充分的測試，建立存儲(chǔ)IOPS與響應(yīng)延遲的模型，這樣我們就可以預(yù)測出性能出現(xiàn)拐點(diǎn)的風(fēng)險(xiǎn)，提前做出擴(kuò)容的判斷。在AWR報(bào)告中，我們可以得到每秒的物理10的數(shù)量和響應(yīng)時(shí)間，可以方便的實(shí)現(xiàn)性能監(jiān)控和趨勢預(yù)警。評(píng)估CPU的容量瓶頸相對(duì)簡單.Oracle中CPUtime的計(jì)算是每個(gè)CPU耗費(fèi)時(shí)間的總和，如果有16顆（核）CPU,1個(gè)小時(shí)理論上可以提供3600X16二57600sCPUtime,不超過57600sCPUtime我們可以認(rèn)為不會(huì)在CPU上排隊(duì)，系統(tǒng)不會(huì)出現(xiàn)CPU瓶頸。但是需要注意的是，除了用戶進(jìn)程使用CPU以外，操作系統(tǒng)也需要占用CPU資源，用來管理內(nèi)存和進(jìn)程調(diào)度等。我們?cè)?S上看到的CPU使用率中的sys部分就是系統(tǒng)占用的CPU資源，所以應(yīng)該考慮至少保留10-20%的CPU資源給OS使用。并發(fā)訪問對(duì)數(shù)據(jù)庫的影響Oracle是一個(gè)Disk-baseddatabase，設(shè)計(jì)的出發(fā)點(diǎn)就是大部分?jǐn)?shù)據(jù)在外部存儲(chǔ)中，而只有小部分?jǐn)?shù)據(jù)被cache在buffer中，它既不同于Memcache這類KVcache,也不同于timesten這類In-memorydatabase。所以，就算是所有的數(shù)據(jù)都可以被cache在buffer中，在高并發(fā)訪問的情況下，也可能會(huì)出現(xiàn)大量的latch等待，最常見的情況就是cachebufferchain0當(dāng)大量并發(fā)訪問同一塊數(shù)據(jù)時(shí),就很可能會(huì)出現(xiàn)cachebufferchain的latch爭用，也就是我們常說的"熱點(diǎn)"。需要注意的是:Oracle中的latch等待分為spin和sleep兩個(gè)部分,spin消耗cputime,而sleep則是等待時(shí)間。所以大量的latch等待不僅僅會(huì)產(chǎn)生大量的等待時(shí)間，而且會(huì)消耗大量的CPUtime。Oracle是一個(gè)為并發(fā)操作而設(shè)計(jì)的數(shù)據(jù)庫，大量的并發(fā)讀寫請(qǐng)求，可能會(huì)帶來額外的性能消耗。比如讀取一部分頻繁修改的數(shù)據(jù)，Oracle為了保證一致性讀的需要，會(huì)利用undo信息構(gòu)造產(chǎn)生大量CRblock,同時(shí)會(huì)產(chǎn)生大疑的邏輯讀，這樣會(huì)消耗額外的CPU和響應(yīng)時(shí)間。存儲(chǔ)也可能存在熱點(diǎn)的問題，需要前期對(duì)存儲(chǔ)系統(tǒng)充分的優(yōu)化，常見的手段是利用RAID技術(shù)，將數(shù)據(jù)分散在不同的磁盤上，防止出現(xiàn)“熱點(diǎn)”盤。OracleASM提供了Rebalance的功能，允許DBA將存儲(chǔ)中的的數(shù)據(jù)重新分布，達(dá)到消除熱點(diǎn)的目的?？傊?，Oracle是一個(gè)可以提供大量并發(fā)讀寫訪問的數(shù)據(jù)庫系統(tǒng)，但是在很多地方，Oracle又不得采用一些串行的控制手段，比如latch,enqueue和mutex,我們要做的就是盡量降低這些串行控制對(duì)數(shù)據(jù)庫整體性能的影響。數(shù)據(jù)庫優(yōu)化原則基于響應(yīng)時(shí)間的Oracle優(yōu)化原則：盡量減少等待時(shí)間(Waittime),提高服務(wù)時(shí)間(Servicetime)。這也是基于0racle等