oracle數據庫性能模型-閱讀頁
2025-07-13 07:57本頁面
【正文】 調優(yōu)的，除CPU time和IO以外的等待時間應該盡可能少（應小于DB time 10%）。 85%DB CPU 5%DB CPU 85%User IO 10%User I/O 因為并沒有考慮硬件和OS上的差異，所以這個數值并不是特別準確，但我們還是可以發(fā)現(xiàn)一些規(guī)律：隨著IO所占比例從10%增加到85%。因為每塊磁盤可以承受的IOPS是基本確定的，比如15K的SAS磁盤，在響應延遲不超過10ms的前提下，可以提供150個IOPS，如果不考慮cache的影響，整個存儲子系統(tǒng)的IOPS是比較容易計算的。在AWR報告中，我們可以得到每秒的物理IO的數量和響應時間，可以方便的實現(xiàn)性能監(jiān)控和趨勢預警。但是需要注意的是，除了用戶進程使用CPU以外，操作系統(tǒng)也需要占用CPU資源，用來管理內存和進程調度等。并發(fā)訪問對數據庫的影響Oracle是一個Diskbased database，設計的出發(fā)點就是大部分數據在外部存儲中，而只有小部分數據被cache在buffer中，它既不同于Memcache這類KV cache，也不同于timesten這類Inmemory database。當大量并發(fā)訪問同一塊數據時，就很可能會出現(xiàn)cache buffer chain的latch爭用，也就是我們常說的“熱點”。所以大量的latch等待不僅僅會產生大量的等待時間，而且會消耗大量的CPU time。比如讀取一部分頻繁修改的數據，Oracle為了保證一致性讀的需要，會利用undo信息構造產生大量CR block，同時會產生大量的邏輯讀，這樣會消耗額外的CPU和響應時間。Oracle ASM提供了Rebalance的功能，允許DBA將存儲中的的數據重新分布，達到消除熱點的目的。數據庫優(yōu)化原則基于響應時間的Oracle優(yōu)化原則：盡量減少等待時間（Wait time），提高服務時間（Service time）。如果數據庫系統(tǒng)除了CPU和IO以外的等待時間超過DB time的5%以上的話，可能存在某些性能問題，需要DBA采用等待事件的分析方法，對系統(tǒng)或應用進行優(yōu)化。之前我們在做SQL優(yōu)化的時候，只是關注這個SQL本身是否優(yōu)化，邏輯讀是多少。關于容量規(guī)劃和風險預測其實是一個很有意義的命題，但是我們很多時候都局限在一些具體的技術細節(jié)中，而忽略了對整個系統(tǒng)容量的把握，事實上，這也是非常難的一件事。在這篇文章中，我提到了幾個有意義的經驗值，這是我根據很多數據庫AWR中的信息計算出來的，雖然不保證完全準確，但是我覺得基本是靠譜的。當面對諸如“硬件是否能夠滿足性能需求”，“系統(tǒng)明年是否需要擴容”，“應用是否會對系統(tǒng)產生影響”此類問題時，我們可以用這些經驗值給出一個判斷。如果大家有興趣，歡迎和我一起探討這個話
環(huán)評公示相關推薦
鄂ICP備17016276號-1