解析4-3

roothomes

解析4-3
Log file single write：該事件僅與寫日志文件頭塊相關(guān)，通常發(fā)生在增加新的組成員和增進(jìn)序列號(hào)時(shí)。頭塊寫單個(gè)進(jìn)行，因?yàn)轭^塊的部分信息是文件號(hào)，每個(gè)文件不同。更新日志文件頭這個(gè)操作在后臺(tái)完成，一般很少出現(xiàn)等待，無需太多關(guān)注。
log file parallel write：從log buffer 寫redo 記錄到redo log 文件，主要指常規(guī)寫操作(相對于log file sync)。如果你的Log group 存在多個(gè)組成員，當(dāng)flush log buffer 時(shí)，寫操作是并行的，這時(shí)候此等待事件可能出現(xiàn)。盡管這個(gè)寫操作并行處理，直到所有I/O 操作完成該寫操作才會(huì)完成(如果你的磁盤支持異步IO或者使用IO SLAVE，那么即使只有一個(gè)redo log file member,也有可能出現(xiàn)此等待)。這個(gè)參數(shù)和log file sync 時(shí)間相比較可以用來衡量log file 的寫入成本。通常稱為同步成本率。改善這個(gè)等待的方法是將redo logs放到I/O快的盤中，盡量不使用raid5，確保表空間不是處在熱備模式下，確保redo log和data的數(shù)據(jù)文件位于不同的磁盤中。
log file sync：當(dāng)一個(gè)用戶提交或回滾數(shù)據(jù)時(shí)，LGWR將會(huì)話的redo記錄從日志緩沖區(qū)填充到日志文件中，用戶的進(jìn)程必須等待這個(gè)填充工作完成。在每次提交時(shí)都出現(xiàn)，如果這個(gè)等待事件影響到數(shù)據(jù)庫性能，那么就需要修改應(yīng)用程序的提交頻率, 為減少這個(gè)等待事件，須一次提交更多記錄，或者將重做日志REDO LOG 文件訪在不同的物理磁盤上，提高I/O的性能。
log buffer space：日志緩沖區(qū)寫的速度快于LGWR寫REDOFILE的速度,可以增大日志文件大小，增加日志緩沖區(qū)的大小，或者使用更快的磁盤來寫數(shù)據(jù)。
logfile switch：通常是因?yàn)闅w檔速度不夠快。表示所有的提交(commit)的請求都需要等待"日志文件切換"的完成。Log file Switch 主要包含兩個(gè)子事件:log file switch (archiving needed) 這個(gè)等待事件出現(xiàn)時(shí)通常是因?yàn)槿罩窘M循環(huán)寫滿以后，第一個(gè)日志歸檔尚未完成，出現(xiàn)該等待。出現(xiàn)該等待，可能表示io 存在問題。解決辦法:①可以考慮增大日志文件和增加日志組；②移動(dòng)歸檔文件到快速磁盤；③調(diào)整log_archive_max_processes。log file switch (checkpoint incomplete) 當(dāng)日志組都寫完以后，LGWR 試圖寫第一個(gè)log file，如果這時(shí)數(shù)據(jù)庫沒有完成寫出記錄在第一個(gè)log file 中的dirty 塊時(shí)(例如第一個(gè)檢查點(diǎn)未完成)，該等待事件出現(xiàn)。該等待事件通常表示你的DBWR 寫出速度太慢或者IO 存在問題。為解決該問題，你可能需要考慮增加額外的DBWR 或者增加你的日志組或日志文件大小，或者也可以考慮增加checkpoint的頻率。
DB File Parallel Write：文件被DBWR并行寫時(shí)發(fā)生。解決辦法：改善IO性能。
DB File Single Write：當(dāng)文件頭或別的單獨(dú)塊被寫入時(shí)發(fā)生，這一等待直到所有的I/O調(diào)用完成。解決辦法：改善IO性能。
DB FILE Scattered Read：當(dāng)掃描整個(gè)段來根據(jù)初始化參數(shù)db_file_multiblock_read_count讀取多個(gè)塊時(shí)發(fā)生，因?yàn)閿?shù)據(jù)可能分散在不同的部分，這與分條或分段）相關(guān)，因此通常需要多個(gè)分散的讀來讀取所有的數(shù)據(jù)。等待時(shí)間是完成所有I/O調(diào)用的時(shí)間。解決辦法：改善IO性能。
DB FILE Sequential Read：當(dāng)前臺(tái)進(jìn)程對數(shù)據(jù)文件進(jìn)行常規(guī)讀時(shí)發(fā)生，包括索引查找和別的非整段掃描以及數(shù)據(jù)文件塊丟棄等待。等待時(shí)間是完成所有I/O調(diào)用的時(shí)間。解決辦法：改善IO性能。
Direct Path Read：一般直接路徑讀取是指將數(shù)據(jù)塊直接讀入PGA中。一般用于排序、并行查詢和read ahead操作。這個(gè)等待可能是由于I/O造成的。使用異步I/O模式或者限制排序在磁盤上，可能會(huì)降低這里的等待時(shí)間。
direct path write：直接路徑寫該等待發(fā)生在，系統(tǒng)等待確認(rèn)所有未完成的異步I/O 都已寫入磁盤。對于這一寫入等待，我們應(yīng)該找到I/O 操作最為頻繁的數(shù)據(jù)文件(如果有過多的排序操作，很有可能就是臨時(shí)文件)，分散負(fù)載，加快其寫入操作。如果系統(tǒng)存在過多的磁盤排序，會(huì)導(dǎo)致臨時(shí)表空間操作頻繁，對于這種情況，可以考慮使用Local管理表空間，分成多個(gè)小文件，寫入不同磁盤或者裸設(shè)備。
control file parallel write：當(dāng)server 進(jìn)程更新所有控制文件時(shí)，這個(gè)事件可能出現(xiàn)。如果等待很短，可以不用考慮。如果等待時(shí)間較長，檢查存放控制文件的物理磁盤I/O 是否存在瓶頸。多個(gè)控制文件是完全相同的拷貝，用于鏡像以提高安全性。對于業(yè)務(wù)系統(tǒng)，多個(gè)控制文件應(yīng)該存放在不同的磁盤上，一般來說三個(gè)是足夠的，如果只有兩個(gè)物理硬盤，那么兩個(gè)控制文件也是可以接受的。在同一個(gè)磁盤上保存多個(gè)控制文件是不具備實(shí)際意義的。減少這個(gè)等待，可以考慮如下方法:①減少控制文件的個(gè)數(shù)(在確保安全的前提下)。②如果系統(tǒng)支持，使用異步IO。③轉(zhuǎn)移控制文件到IO 負(fù)擔(dān)輕的物理磁盤。
control file sequential read control file single write ：控制文件連續(xù)讀/控制文件單個(gè)寫對單個(gè)控制文件I/O 存在問題時(shí)，這兩個(gè)事件會(huì)出現(xiàn)。如果等待比較明顯，檢查單個(gè)控制文件，看存放位置是否存在I/O 瓶頸。