解析4-2

roothomes

解析4-2
如果這一等待位于undo header，可以通過增加回滾段(rollback segment)來解決緩沖區(qū)的問題。
如果等待位于undo block上，我們需要增加提交的頻率，使block可以盡快被重用；使用更大的回滾段；降低一致讀所選擇的表中數(shù)據(jù)的密度；增大DB_CACHE_SIZE。
如果等待處于data block，表明出現(xiàn)了hot block，可以考慮如下方法解決： ①將頻繁并發(fā)訪問的表或數(shù)據(jù)移到另一數(shù)據(jù)塊或者進行更大范圍的分布(可以增大pctfree值 ，擴大數(shù)據(jù)分布，減少競爭)，以避開這個"熱點"數(shù)據(jù)塊。②也可以減小數(shù)據(jù)塊的大小，從而減少一個數(shù)據(jù)塊中的數(shù)據(jù)行數(shù)，降低數(shù)據(jù)塊的熱度，減小競爭；③檢查對這些熱塊操作的SQL語句，優(yōu)化語句。④增加hot block上的initrans值。但注意不要把initrans值設(shè)置的過于高了，通常設(shè)置為5就足夠了。因為增加事務(wù)意味著要增加ITL事務(wù)槽，而每個ITL事務(wù)槽將占用數(shù)據(jù)塊中24個字節(jié)長度。默認情況下，每個數(shù)據(jù)塊或者索引塊中是ITL槽是2個，在增加initrans的時候，可以考慮增大數(shù)據(jù)塊所在的表的PCTFREE值，這樣Oracle會利用PCTFREE部分的空間增加ITL slot數(shù)量，最大達到maxtrans指定。
如果等待處于index block，應(yīng)該考慮重建索引、分割索引或使用反向鍵索引。為了防止與數(shù)據(jù)塊相關(guān)的緩沖忙等待，也可以使用較小的塊，在這種情況下，單個塊中的記錄就較少，所以這個塊就不是那么"繁忙"。或者可以設(shè)置更大的PCTFREE,使數(shù)據(jù)擴大物理分布，減少記錄間的熱點競爭。在執(zhí)行DML (insert/update/ delete)時，Oracle向數(shù)據(jù)塊中寫入信息，對于多事務(wù)并發(fā)訪問的數(shù)據(jù)表，關(guān)于ITL的競爭和等待可能出現(xiàn)，為了減少這個等待，可以增加initrans，使用多個ITL槽。在Oracle9i 中，可以使用ASSM這個新特性O(shè)racle 使用位圖來管理空間使用，減小爭用。
latch free：當(dāng)閂鎖丟失率高于0.5%時，需要調(diào)整這個問題。詳細的我們在后面的Latch Activity for DB部分說明。
Enqueue 隊列是一種鎖，保護一些共享資源，防止并發(fā)的DML操作。隊列采用FIFO策略，注意latch并不是采用的FIFO機制。比較常見的有3種類型的隊列：ST隊列，HW隊列，TX4隊列。ST Enqueue的等待主要是在字典管理的表空間中進行空間管理和分配時產(chǎn)生的。解決方法：1）將字典管理的表空間改為本地管理模式 2）預(yù)先分配分區(qū)或者將有問題的字典管理的表空間的next extent設(shè)置大一些。HW Enqueue是用于segment的HWM的。當(dāng)出現(xiàn)這種等待的時候，可以通過手工分配etents來解決。TX4 Enqueue等待是最常見的等待情況。通常有3種情況會造成這種類型的等待：1）唯一索引中的重復(fù)索引。解決方法：commit或者rollback以釋放隊列。 2）對同一個位圖索引段（bitmap index fragment）有多個update，因為一個bitmap index fragment可能包含了多個rowid，所以當(dāng)多個用戶更新時，可能一個用戶會鎖定該段，從而造成等待。解決方法同上。3）有多個用戶同時對一個數(shù)據(jù)塊作update，當(dāng)然這些DML操作可能是針對這個數(shù)據(jù)塊的不同的行，如果此時沒有空閑的ITL槽，就會產(chǎn)生一個block-level鎖。解決方法：增大表的initrans值使創(chuàng)建更多的ITL槽；或者增大表的pctfree值，這樣oracle可以根據(jù)需要在pctfree的空間創(chuàng)建更多的ITL槽；使用smaller block size，這樣每個塊中包含行就比較少，可以減小沖突發(fā)生的機會。
Free Buffer：這個等待事件表明系統(tǒng)正在等待內(nèi)存中的可用空間，這說明當(dāng)前Buffer 中已經(jīng)沒有Free 的內(nèi)存空間。如果應(yīng)用設(shè)計良好，SQL 書寫規(guī)范，充分綁定變量，那這種等待可能說明Buffer Cache 設(shè)置的偏小，你可能需要增大DB_CACHE_SIZE。該等待也可能說明DBWR 的寫出速度不夠，或者磁盤存在嚴重的競爭，可以需要考慮增加檢查點、使用更多的DBWR 進程，或者增加物理磁盤的數(shù)量,分散負載，平衡IO。