參數(shù)
讓我們進(jìn)一步看看CPU的數(shù)量是如何影響這些參數(shù)的。
參數(shù)fast_start_parallel_rollback
Oracle并行機(jī)制中一個令人興奮之處是在系統(tǒng)崩潰時調(diào)用并行回滾得能力。當(dāng)Oracle數(shù)據(jù)庫發(fā)生少有的崩潰時，Oracle能自動檢測未完成的事務(wù)并回滾到起始狀態(tài)。這被稱為并行熱啟動，而Oracle使用基于cpu_count的fast_start_parallel_rollback參數(shù)來決定未完成事務(wù)的秉性程度。
并行數(shù)據(jù)操縱語言(DML)恢復(fù)能夠在Oracle數(shù)據(jù)庫崩潰后極大地加快其重新啟動的速度。此參數(shù)的默認(rèn)值是系統(tǒng)CPU數(shù)量的兩倍，但是一些DBA們認(rèn)為應(yīng)該將這個值設(shè)置為cpu_count的四倍。
參數(shù)parallel_max_servers_parameter
Oracle一個顯著的加強(qiáng)是自動決定OPQ并行的程度。由于Oracle清楚服務(wù)器中CPU的數(shù)量，它會自動分配合適的子進(jìn)程的數(shù)量來提升并行查詢的響應(yīng)時間。當(dāng)然，會有其它的外部因素，比如表的劃分以及磁盤輸入/輸出子系統(tǒng)的布局等，但是根據(jù)cpu_count來設(shè)置parallel_max_servers參數(shù)將給Oracle一個合理的依據(jù)來選擇并行的程度。
由于Oracle的并行操作嚴(yán)重依賴服務(wù)器上CPU的數(shù)量，parallel_max_servers會被設(shè)置成服務(wù)器上CPU的數(shù)量。如果在一臺服務(wù)器上運(yùn)行多個實(shí)例，則默認(rèn)值太大了，會導(dǎo)致過度的頁面交換和嚴(yán)重的CPU負(fù)擔(dān)。并行的程度還依賴于目標(biāo)表中分區(qū)的數(shù)量，因此parallel_max_servers應(yīng)該設(shè)置成足夠大以允許Oracle為每個查詢選擇最佳數(shù)量的并行子查詢。
參數(shù)log_buffer
參數(shù)log_buffer定義了供即刻寫入redo日志信息的保留RAM的數(shù)量，這個參數(shù)受cpu_count的影響。Oracle推薦log_buffer最大為cpu_count乘以500KB或128KB。CPU的數(shù)量對于log_buffer來說非常重要，因?yàn)镺racle會生成多日志寫入(LGWR)進(jìn)程來異步釋放redo信息。
log_buffer是Oracle中最易誤解的的RAM參數(shù)之一，通常存在下面幾個配置錯誤：
log_buffer被設(shè)置得太高(例如，大于1MB)，這回引起性能問題，因?yàn)榇笕萘康慕Y(jié)果會使得寫入同步進(jìn)行(例如，日志同步等待事件非常高)。
log_buffer 在一個單獨(dú)的服務(wù)器中安裝更多的CPU成為目前的一個趨勢。使用對稱多處理服務(wù)器(SMP)的情況下，一個Oracle服務(wù)器擁有8個、16個或32個CPU以及幾吉比特RAM的SGA都不足為奇。
Oracle跟上了硬件發(fā)展的步伐，提供了很多面向多CPU的功能。從Oracle8i開始，Oracle在每個數(shù)據(jù)庫函數(shù)中都實(shí)現(xiàn)了并行性，包括SQL訪問(全表檢索)、并行數(shù)據(jù)操作和并行恢復(fù)。對于Oracle專業(yè)版的挑戰(zhàn)是為用戶的數(shù)據(jù)庫配置盡可能多的CPU。
在Oracle環(huán)境中實(shí)現(xiàn)并行性最好的方法之一是使用Oracle并行查詢(OPQ)。我將討論OPQ是如何工作的和怎樣用它來提升大的全表檢索的響應(yīng)時間以及調(diào)用并行事務(wù)回滾等等。
使用OPQ
圖
當(dāng)在Oracle中進(jìn)行一次合法的、大型的全表檢索時，OPQ能夠極大地提高響應(yīng)時間。通過OPQ，Oracle將表劃分成如所示的邏輯塊。
圖 A
由OPQ劃分的表
一旦表被劃分成塊，Oracle啟用并行的子查詢(有時稱為雜務(wù)進(jìn)程)，每個子查詢同時讀取一個大型表中的一塊。所有子查詢完畢以后，Oracle將結(jié)果會傳給并行查詢調(diào)度器，它會重新安排數(shù)據(jù)，如果需要則進(jìn)行排序，并且將結(jié)果傳遞給最終用戶。OPQ具有無限的伸縮性，因此，以前需要花費(fèi)幾分鐘的全表檢索現(xiàn)在的響應(yīng)時間卻不到1秒。
OPQ嚴(yán)重依賴于處理器的數(shù)量，通過并行運(yùn)行之所以可以極大地提升全表檢索的性能，其前提就是使用了N-1個并行進(jìn)程(N=Oracle服務(wù)器上CPU的數(shù)量)。
必須注意非常重要的一點(diǎn)，即Oracle9i能夠自動檢測外部環(huán)境，包括服務(wù)器上CPU的數(shù)量。在安裝時，Oracle9i會檢查服務(wù)器上CPU的數(shù)量，設(shè)置一個名為cpu_count的參數(shù)，并使用cpu_count作為默認(rèn)的初始化輸入?yún)?shù)。這些初始化參數(shù)會影響到Oracle對內(nèi)部查詢的處理。
下面就是Orale在安裝時根據(jù)cpu_count而設(shè)置的一些參數(shù)：
fast_start_parallel_rollback
parallel_max_servers
log_buffer
db_block_lru_latches
[NextPage]
不是db_block_size的倍數(shù)。在的Oracle9i中，log_buffer應(yīng)該是2048字節(jié)的倍數(shù)。
參數(shù)db_block_lru_latches
LRU鎖的數(shù)量是在Oracle數(shù)據(jù)庫內(nèi)部用來管理數(shù)據(jù)庫緩沖的，這嚴(yán)重依賴于服務(wù)器上CPU的數(shù)量。
很多聰明的Oracle9i的DBA使用多沖數(shù)據(jù)緩沖(例如db_32k_cache_size)，他們推薦將這個未公開聲明的參數(shù)重設(shè)置為默認(rèn)的最大值。db_block_lru_latches參數(shù)在Oracle8i中使用得很多，但是在Oracle9i中變成了一個未公開聲明的參數(shù)，因?yàn)镺racle現(xiàn)在根據(jù)數(shù)據(jù)庫擁有的CPU數(shù)量設(shè)置了一個合理的默認(rèn)值。
db_block_lru_latches默認(rèn)被設(shè)置為服務(wù)器上cpu_count的一半(例如服務(wù)器上只有一個Oracle數(shù)據(jù)庫)。Oracle推薦db_block_lru_latches千萬不要超過cpu_count的兩倍或三倍，或db_block_buffers的五十分之一。
如果使用多緩沖池則這種計(jì)算方法有一個問題，因?yàn)椴荒芸刂品峙浣o每個數(shù)據(jù)緩沖池的鎖的數(shù)量。如果db_writers參數(shù)大于1，則默認(rèn)值或許顯得太小。
加強(qiáng)服務(wù)器
Oracle數(shù)據(jù)庫總是在提升性能，根據(jù)外部服務(wù)器環(huán)境檢測cpu_count和基本參數(shù)設(shè)置的能力對于Oracle軟件來說是一個重要的加強(qiáng)。
隨著更多的Oracle系統(tǒng)轉(zhuǎn)移到SMP上來，當(dāng)客戶要采取增強(qiáng)措施并將眾多的數(shù)據(jù)庫轉(zhuǎn)移到擁有32個或64個CPU的巨大服務(wù)器上來的時候，這些參數(shù)顯得愈發(fā)重要。
