【正文】 Redo size: 是日志的生成量，分為每秒和每事務(wù)所產(chǎn)生的，通常在很繁忙的系統(tǒng)中日志生成量可能達(dá)到上百k，甚至幾百k； Logical reads: 邏輯讀實(shí)際上就是logical IO=buffer gets表示的含義，我們可以這樣認(rèn)為，block在內(nèi)存中，我們每一次讀一塊內(nèi)存，就相當(dāng)于一次邏輯讀； Parses 和 Hard parses: Parse 和 hard parse通常是很容易出問題的部分，80%的系統(tǒng)的慢都是由于這個(gè)原因所導(dǎo)致的。 所謂parse分soft parse 和hard parse，soft parse是當(dāng)一條sql傳進(jìn)來后，需要在shared pool中找是否有相同的sql，如果找到了，那就是soft parse，如果沒有找著，那就開始hard parse，實(shí)際上hard parse主要是檢查該sql所涉及到的所有的對(duì)象是否有效以及權(quán)限等關(guān)系，hard parse之后才根據(jù)rule/cost模式生成執(zhí)行計(jì)劃，再執(zhí)行sql。 而hard parse的根源，基本都是由于不使用bind var所導(dǎo)致的，不使用bind var違背了oracle的shared pool的設(shè)計(jì)的原則，違背了這個(gè)設(shè)計(jì)用來共享的思想，這樣導(dǎo)致shared_pool_size里面命中率下降。因此不使用bind var，將導(dǎo)致cpu使用率的問題，極有使得性能急劇下降。 還有就是為了維護(hù)internal structure，需要使用latch，latch是一種Oracle低級(jí)結(jié)構(gòu),用于保護(hù)內(nèi)存資源，是一種內(nèi)部生命周期很短的lock，大量使用latch將消耗大量的cpu資源。 Sorts: 表示排序的數(shù)量； Executes: 表示執(zhí)行次數(shù)； Transactions: 表示事務(wù)數(shù)量； Rollback per transaction %: 表示數(shù)據(jù)庫中事務(wù)的回退率。如果不是因?yàn)闃I(yè)務(wù)本身的原因，通常應(yīng)該小于10%為好，回退是一個(gè)很消耗資源的操作。 Instance Efficiency Percentages (Target 100%) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Buffer Nowait %: Redo NoWait %: Buffer Hit %: Inmemory Sort %: Library Hit %: Soft Parse %: Execute to Parse %: Latch Hit %: Parse CPU to Parse Elapsd %: % NonParse CPU: Buffer Hit %: 數(shù)據(jù)緩沖區(qū)命中率，通常應(yīng)該大于90%； Library Hit %: libaray cache的命中率，通常應(yīng)該大于98%； Inmemory Sort %: 排序在內(nèi)存的比例，如果這個(gè)比例過小，可以考慮增大sort_area_size，使得排序在內(nèi)存中進(jìn)行而不是在temp表空間中進(jìn)行； Soft Parse %: 軟解析的百分比，這個(gè)百分比也應(yīng)該很大才好，因?yàn)槲覀円M量減少hard parse。 soft parse 百分比=soft/(soft+hard)； Execute to Parse %: 這個(gè)數(shù)字也應(yīng)該是越大越好，接近100%最好。有些報(bào)告中這個(gè)值是負(fù)的，看上去很奇怪。事實(shí)上這表示一個(gè)問題，sql如果被age out的話就可能出現(xiàn)這種情況，也就是sql老化，或執(zhí)行alter system flush shared_pool等。 Shared Pool Statistics Begin End Memory Usage %: % SQL with executions1: % Memory for SQL w/exec1: % SQL with executions1: 這個(gè)表示SQL被執(zhí)行次數(shù)多于一次的比率，也應(yīng)該大為好，小則表示很多sql只被執(zhí)行了一次，說明沒有使用bind var； 等待事件分析 接下來，statspack報(bào)告中描述的是等待事件（Wait Events），這是Oracle中比較復(fù)雜難懂的概念。 Oracle 的等待事件是衡量Oracle 運(yùn)行狀況的重要依據(jù)及指標(biāo)。 中引入的，大致有100 個(gè)等待事件。在Oracle 中這個(gè)數(shù)目增加到了大約150 個(gè)，在Oracle8i 中大約有200 個(gè)事件,在Oracle9i 中大約有360 個(gè)等待事件。 主要有兩種類別的等待事件，即空閑（idle）等待事件和非空閑（nonidle）等待事件。 空閑事件指Oracle 正等待某種工作,在診斷和優(yōu)化數(shù)據(jù)庫的時(shí)候,我們不用過多注意這部分事件。 常見的空閑事件有: ? dispatcher timer ? lock element cleanup ? Null event ? parallel query dequeue wait ? parallel query idle wait Slaves ? pipe get ? PL/SQL lock timer ? pmon timer pmon ? rdbms ipc message ? slave wait ? smon timer ? SQL*Net break/reset to client ? SQL*Net message from client ? SQL*Net message to client ? SQL*Net more data to client ? virtual circuit status ? client message 非空閑等待事件專門針對(duì)Oracle 的活動(dòng),指數(shù)據(jù)庫任務(wù)或應(yīng)用運(yùn)行過程中發(fā)生的等待，這些等待事件是我們?cè)谡{(diào)整數(shù)據(jù)庫的時(shí)候應(yīng)該關(guān)注與研究的。 一些常見的非空閑等待事件有: ? db file scattered read ? db file sequential read ? buffer busy waits ? free buffer waits ? enqueue ? latch free ? log file parallel write ? log file sync 下面接合statspack中的一些等待事件進(jìn)行講述。 Top 5 Wait Events ~~~~~~~~~~~~~~~~~ Wait % Total Event Waits Time (cs) Wt Time db file scattered read 26,877 12,850 db file parallel write 472 3,674 log file parallel write 975 1,560 direct path write 1,571 1,543 control file parallel write 652 1,290 db file scattered read: DB文件分散讀取。這個(gè)等待事件很常見，經(jīng)常在top5中出現(xiàn)，這表示，一次從磁盤讀數(shù)據(jù)進(jìn)來的時(shí)候讀了多于一個(gè)block的數(shù)據(jù)，而這些數(shù)據(jù)又被分散的放在不連續(xù)的內(nèi)存塊中，因?yàn)橐淮巫x進(jìn)來的是多于一個(gè)block的。 通常來說我們可以認(rèn)為是全表掃描類型的讀，因?yàn)楦鶕?jù)索引讀表數(shù)據(jù)的話一次只讀一個(gè)block，如果這個(gè)數(shù)字過大，就表明該表找不到索引，或者只能找到有限的索引，可能是全表掃描過多，需要檢查sql是否合理的利用了索引，或者是否需要建立合理的索引。 當(dāng)全表掃描被限制在內(nèi)存時(shí)，它們很少會(huì)進(jìn)入連續(xù)的緩沖區(qū)內(nèi)，而是分散于整個(gè)緩沖存儲(chǔ)器中。盡管在特定條件下執(zhí)行全表掃描可能比索引掃描更有效，但如果出現(xiàn)這種等待時(shí)，最好檢查一下這些全表掃描是否必要,是否可以通過建立合適的索引來減少對(duì)于大表全表掃描所產(chǎn)生的大規(guī)模數(shù)據(jù)讀取。 對(duì)于經(jīng)常使用的小表，應(yīng)該盡量把他們pin 在內(nèi)存中，避免不必要的老化清除及重復(fù)讀取。 db file sequential read: DB文件連續(xù)讀取。通常顯示單個(gè)塊的讀取(通常指索引讀取)，表示的是讀進(jìn)磁盤的block被放在連續(xù)的內(nèi)存塊中。 事實(shí)上大部分基本代表著單個(gè)block的讀入，可以說象征著 IO 或者說通過索引讀入的比較多 。因?yàn)橐淮蜪O若讀進(jìn)多個(gè)的block，放入連續(xù)的內(nèi)存塊的幾率是很小的，分布在不同block的大量記錄被讀入就會(huì)遇到此事件。因?yàn)楦鶕?jù)索引讀數(shù)據(jù)的話，假設(shè)100條記錄，根據(jù)索引，不算索引本身的讀，而根據(jù)索引每個(gè)值去讀一下表數(shù)據(jù)，理論上最多可能產(chǎn)生100 buffer gets，而如果是full table scan，則100條數(shù)據(jù)完全可能在一個(gè)block里面，則幾乎一次就讀過這個(gè)block了，就會(huì)產(chǎn)生這么大的差異。 這種等待的數(shù)目很多時(shí)，可能顯示表的連接順序不佳，或者不加選擇地進(jìn)行索引。 對(duì)于高級(jí)事務(wù)處理（hightransaction）、調(diào)整良好（welltuned）的系統(tǒng)，這一數(shù)值很大是很正常的，但在某些情況下，它可能暗示著系統(tǒng)中存在問題。 你應(yīng)當(dāng)將這一等待統(tǒng)計(jì)量與Statspack 報(bào)告中的已知問題（如效率較低的SQL）聯(lián)系起來。檢查索引掃描，以保證每個(gè)掃描都是必要的，并檢查多表連接的連接順序。 DB_CACHE_SIZE 也是這些等待出現(xiàn)頻率的決定因素。有問題的散列區(qū)域（Hasharea）連接應(yīng)當(dāng)出現(xiàn)在PGA 內(nèi)存中，但它們也會(huì)消耗大量?jī)?nèi)存，從而在順序讀取時(shí)導(dǎo)致大量等待。它們也可能以直接路徑讀／寫等待的形式出現(xiàn)。 Free Buffer Wait: 釋放緩沖區(qū)。 這種等待表明系統(tǒng)正在等待內(nèi)存中的緩沖，因?yàn)閮?nèi)存中已經(jīng)沒有可用的緩沖空間了。如果所有SQL 都得到了調(diào)優(yōu)，這種等待可能表示你需要增大DB_BUFFER_CACHE。釋放緩沖區(qū)等待也可能表示不加選擇的SQL 導(dǎo)致數(shù)據(jù)溢出了帶有索引塊的緩沖存儲(chǔ)器，沒有為等待系統(tǒng)處理的特定語句留有緩沖區(qū)。 這種情況通常表示正在執(zhí)行相當(dāng)多數(shù)量的DML（插入／更新／刪除），并且可能說明DBWR 寫的速度不夠快，緩沖存儲(chǔ)器可能充滿了相同緩沖器的多個(gè)版本，從而導(dǎo)致效率非常低。為了解決這個(gè)問題，可能需要考慮增加檢查點(diǎn)、利用更多的DBWR 進(jìn)程，或者增加物理磁盤的數(shù)量。 Buffer Busy Wait: 緩沖區(qū)忙。 該等待事件表示正在等待一個(gè)以u(píng)nshareable方式使用的緩沖區(qū)，或者表示當(dāng)前正在被讀入buffer cache。也就是當(dāng)進(jìn)程想獲取或者操作某個(gè)block的時(shí)候卻發(fā)現(xiàn)被別的進(jìn)程在使用而出現(xiàn)等待。一般來說Buffer Busy Wait不應(yīng)大于1%。 檢查緩沖等待統(tǒng)計(jì)部分（或V$WAITSTAT），看一下等待是否位于段頭。如果是，可以考慮增加自由列表（freelist，對(duì)于Oracle8i DMT）或者增加freelist groups. 其修改語法為： SQL alter table sp_item storage (freelists 2)。 Table altered。 對(duì)于Oracle8i而言，增加freelist參數(shù)，在很多時(shí)候可以明顯緩解等待，如果使用LMT，也就是Local Manangement Tablespace，區(qū)段的管理就相對(duì)簡(jiǎn)單還可以考慮修改數(shù)據(jù)塊的pctused\pctfree值，比如增大pctfree可以擴(kuò)大數(shù)據(jù)的分布，在某種程度上就可以減少熱點(diǎn)塊的競(jìng)爭(zhēng)。 如果這一等待位于undo header，可以通過增加回滾段（rollback segment）來解決緩沖區(qū)的問題。 如果等待位于undo block上，我們可能需要檢查相關(guān)應(yīng)用，適當(dāng)減少大規(guī)模的一致性讀取，或者降低一致性讀取(consistent read)的表中的數(shù)據(jù)密度或者增大DB_CACHE_SIZE。 如果等待處于data block，可以考慮將頻繁并發(fā)訪問的表或數(shù)據(jù)移到另一數(shù)據(jù)塊或者進(jìn)行更大范圍的分布（可以增加pctfree 值 ，擴(kuò)大數(shù)據(jù)分布，減少競(jìng)爭(zhēng)），以避開這個(gè)熱點(diǎn)數(shù)據(jù)塊，或者可以考慮增加表中的自由列表或使用本地化管理的表空間（Locally Managed Tablespaces）。 如果等待處于索引塊，應(yīng)該考慮重建索引、分割索引或使用反向鍵索引。反向鍵索引在很多情況下，可以極大地緩解競(jìng)爭(zhēng)，其原理有點(diǎn)類似于hash分區(qū)的功效。反向鍵索引（reverse key index）常建在一些值是連續(xù)增長(zhǎng)的列上，例如列中的值是由sequence產(chǎn)生的。 為了防止與數(shù)據(jù)塊相關(guān)的緩沖忙等待，也可以使用較小的塊：在這種情況下，單個(gè)塊中的記錄就較少，所以這個(gè)塊就不是那么繁忙；或者可以設(shè)置更大的pctfree,使數(shù)據(jù)擴(kuò)大物理分布，減少記錄間的熱點(diǎn)競(jìng)爭(zhēng)。 在執(zhí)行DML (insert/update/ delete)時(shí)，Oracle向數(shù)據(jù)塊中寫入信息，對(duì)于多事務(wù)并發(fā)