oracle數(shù)據(jù)庫性能模型-資料下載頁
2025-06-28 07:57本頁面
【正文】 等待時(shí)間。所以大量的latch等待不僅僅會(huì)產(chǎn)生大量的等待時(shí)間，而且會(huì)消耗大量的CPU time。Oracle是一個(gè)為并發(fā)操作而設(shè)計(jì)的數(shù)據(jù)庫，大量的并發(fā)讀寫請(qǐng)求，可能會(huì)帶來額外的性能消耗。比如讀取一部分頻繁修改的數(shù)據(jù)，Oracle為了保證一致性讀的需要，會(huì)利用undo信息構(gòu)造產(chǎn)生大量CR block，同時(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)”盤。Oracle ASM提供了Rebalance的功能，允許DBA將存儲(chǔ)中的的數(shù)據(jù)重新分布，達(dá)到消除熱點(diǎn)的目的?？傊琌racle是一個(gè)可以提供大量并發(fā)讀寫訪問的數(shù)據(jù)庫系統(tǒng)，但是在很多地方，Oracle又不得采用一些串行的控制手段，比如latch，enqueue和mutex，我們要做的就是盡量降低這些串行控制對(duì)數(shù)據(jù)庫整體性能的影響。數(shù)據(jù)庫優(yōu)化原則基于響應(yīng)時(shí)間的Oracle優(yōu)化原則：盡量減少等待時(shí)間（Wait time），提高服務(wù)時(shí)間（Service time）。這也是基于Oracle等待事件的分析方法的基本原則：盡量消除各種等待事件對(duì)系統(tǒng)的影響，從而提高系統(tǒng)性能和響應(yīng)時(shí)間。如果數(shù)據(jù)庫系統(tǒng)除了CPU和IO以外的等待時(shí)間超過DB time的5%以上的話，可能存在某些性能問題，需要DBA采用等待事件的分析方法，對(duì)系統(tǒng)或應(yīng)用進(jìn)行優(yōu)化。–EOF–后記：為什么要寫這么一個(gè)主題，因?yàn)樽罱鸵晃煌绿接憴C(jī)器自動(dòng)審核SQL的問題，就想建立一個(gè)簡單的模型，用來開發(fā)一個(gè)SQL審核工具，開發(fā)人員通過工具和預(yù)先建立好的模型，就可以確定這個(gè)SQL是否存在性能風(fēng)險(xiǎn)。之前我們?cè)谧鯯QL優(yōu)化的時(shí)候，只是關(guān)注這個(gè)SQL本身是否優(yōu)化，邏輯讀是多少。但是，很少有人把邏輯讀和響應(yīng)時(shí)間之間的關(guān)系建立起來，我試圖想回答這個(gè)問題。關(guān)于容量規(guī)劃和風(fēng)險(xiǎn)預(yù)測其實(shí)是一個(gè)很有意義的命題，但是我們很多時(shí)候都局限在一些具體的技術(shù)細(xì)節(jié)中，而忽略了對(duì)整個(gè)系統(tǒng)容量的把握，事實(shí)上，這也是非常難的一件事。也許到目前為止，我根本沒有達(dá)到建立“模型”的程度，但是我試圖將這些方方面面的因素聯(lián)系起來，提供一些有用的經(jīng)驗(yàn)值給大家，我覺得這個(gè)挺有意義。在這篇文章中，我提到了幾個(gè)有意義的經(jīng)驗(yàn)值，這是我根據(jù)很多數(shù)據(jù)庫AWR中的信息計(jì)算出來的，雖然不保證完全準(zhǔn)確，但是我覺得基本是靠譜的。建議每個(gè)DBA都應(yīng)該從AWR中找到這些信息，并判斷自己的數(shù)據(jù)庫屬于哪種類型，瓶頸在哪里，是否存在性能風(fēng)險(xiǎn)。當(dāng)面對(duì)諸如“硬件是否能夠滿足性能需求”，“系統(tǒng)明年是否需要擴(kuò)容”，“應(yīng)用是否會(huì)對(duì)系統(tǒng)產(chǎn)生影響”此類問題時(shí)，我們可以用這些經(jīng)驗(yàn)值給出一個(gè)判斷。關(guān)于這個(gè)命題，目前只是一個(gè)階段性的結(jié)果，我還會(huì)繼續(xù)思考。如果大家有興趣，歡迎和我一起探討這個(gè)話題。8 /
環(huán)評(píng)公示相關(guān)推薦
鄂ICP備17016276號(hào)-1