oracle數(shù)據(jù)庫性能模型-文庫吧
2025-06-13 07:57 本頁面
【正文】 總時間，是從第一項到第十項時間的總和（從sql execute elapsed time到PL/SQL pilation elapsed time），但是我們會發(fā)現(xiàn)這十項時間的總和比DB Time要大一些，這是因為部分時間信息有重疊的部分，比如SQL execute elapsed time就包括了很大一部分DB cpu的時間。而background elapsed time和background cpu time則是Oracle后臺進程消耗的時間和cpu time。數(shù)據(jù)庫響應(yīng)時間分析：數(shù)據(jù)庫系統(tǒng)的響應(yīng)時間由四個要素決定：CPU，IO，內(nèi)存和網(wǎng)絡(luò)，其中CPU和IO是最重要的因素。與之相比，內(nèi)存與網(wǎng)絡(luò)則簡單很多，因為通常情況下，對于一個調(diào)優(yōu)的系統(tǒng)來說，內(nèi)存訪問的延遲時間非常?。?00 ns以下，1 ms=1000000 ns）相比較CPU和IO幾乎可以忽略。而網(wǎng)絡(luò)延遲則通常是一個常數(shù)，比如在一個數(shù)據(jù)中心的情況下，網(wǎng)絡(luò)的延遲一般在3ms以下，如果存在多數(shù)據(jù)中心的情況，網(wǎng)絡(luò)延遲可能會超過20ms，所以對于一個分布式系統(tǒng)來說，網(wǎng)絡(luò)延遲是必須要考慮的問題。在這里，我們不考慮分布式系統(tǒng)，并且忽略內(nèi)存的訪問延遲，重點分析CPU和IO，我們看以下數(shù)據(jù)庫的AWR片段：我們看到這個系統(tǒng)中DB CPU占整個DB %，User I/O占整個DB %，%（主要是log file sync），CPU和IO占用了整個DB %。由于DB CPU所占的比例很高，所以這個數(shù)據(jù)庫系統(tǒng)是CPU intensive類型，這里的DB CPU主要是執(zhí)行SQL的服務(wù)時間。我們再看另外的一個數(shù)據(jù)庫的AWR片段：我們看到，Commit和User I/O占DB %，而DB %，所以這個數(shù)據(jù)庫系統(tǒng)是IO instensive類型的。Physical readPhysical read是指Oracle在buffer cache中沒有找到相應(yīng)的block，需要從IO子系統(tǒng)讀取相應(yīng)的block的過程，對應(yīng)的IO稱為物理IO，物理讀數(shù)量代表物理IO讀取的block數(shù)量。因為一般IO子系統(tǒng)都是慢速的磁盤，所以物理IO對整體響應(yīng)時間的影響非常大，如果發(fā)生大量的物理IO，整個系統(tǒng)的響應(yīng)時間會變得很差。系統(tǒng)的IO子系統(tǒng)可能是文件系統(tǒng)，裸設(shè)備或者ASM，底層硬件可能是SAN存儲，NAS存儲或者普通SAS磁盤等等。為了提高響應(yīng)時間，通常在物理磁盤與Oracle之間增加cache層，對于Oracle來說，物理IO并不一定是真正訪問磁盤，很可能是訪問文件系統(tǒng)cache，存儲的cache等等。不管IO subsystem是什么，Oracle只關(guān)心物理IO的響應(yīng)時間。通過AWR報告，我們可以看到物理IO的響應(yīng)時間：db file sequential read（單塊讀，隨機IO）的平均響應(yīng)時間為3ms
環(huán)評公示相關(guān)推薦
鄂ICP備17016276號-1