RAC數據庫集群服務器系統性能瓶頸分析(zt)

RAC數據庫集群服務器系統性能瓶頸分析(zt)OracleRAC性能調整1、CPU和waittime調節(jié)尺寸當在調節(jié)system時，比較系統的CPUtime和waittime是十分重要的，從而確定在相應時間中多少是用于有效的工作時間，多少是在等待由其他進程占用的資源。從一般規(guī)律來看，waittime占主要部分的系統比CPUtime占主要部分的系統更需要調節(jié)。另一方面，CPU的大量使用可能是由不好的SQL寫操作造成了。盡管CPUtime與waittime的比率總是隨著系統裝載的增加而趨于減小的，waittime的急劇增加是存在沖突的表現，必須被有效的處理。給node增加更多的CPUs或是給cluster增加nodes，在資源競爭中提供的benefit是非常有限的。相反，當加載系統裝載增加時，CPUtime的比率沒有大幅下降的系統可能規(guī)模較好，更可能通過添加CPUs或是RACInstances獲得更多的benefit。 note:如果CPUtime比率在前五個事件中，則automaticworkloadrepository(AWR)報告在Top5Event段中顯示了CPU時間和wait時間。2、RAC特有的調節(jié)盡管對于RAC有其特有的調節(jié)方法，例如互聯的傳輸但通過對每個Instance進行像single-instance系統那樣的調節(jié)會帶來較大的benefit。至少它應該tuning的第一步。顯然，如果在single-Instance環(huán)境中存在序列化問題，在RAC中，該問題會更加嚴重。RAC-reactive調節(jié)工具主要有：特定的等待事件、系統和隊列統計、databasecontrol性能頁面、statspack和AWR報告RAC-proactive調節(jié)工具：AWRsnapshots、ADDM(AutomaticDatabaseDiagnosticMonitor)報告 如上，RAC的調節(jié)工具和single-Instance系統的基本類似。但部分特殊等待事件和統計信息的結合是RAC比較關鍵的調節(jié)情況。3、 分析在RAC中cachefusion(緩沖融合)的影響在全局緩沖中訪問blocks的影響和維護cache的相融合(coherency)是通過下面來表現的： *對當前和crblocks的全局緩沖服務統計：例如，gc當前的blocksreceived、gccrblocksreceived等。*全局緩沖服務等待事件(對gc當前block3-way、gccrgrant2-way等)cachefusion傳輸的響應時間是由物理交換鏈接組件、IPC協議和GCS協議使用的messaging時間和processing時間決定的。 除了相關的log寫操作，它是不受磁盤I/O因素的影響的。cachefusion協議不需要對datafiles進行I/O，從而確保緩沖的coherency。并且RAC并不會引起比非clusteredInstance更多的I/O操作。4、RAC操作特有的潛在因素 在RACAWR報告中，在RAC統計一章包含了一個表，用于記錄一些全局cacheservices和全局隊列services操作的平均時間。該表被稱作是GlobalcacheandEnqueueservices:workloadcharacteristics。這些潛在因素應該得到定期的監(jiān)控，并且應該對部分值的重大增加進行調查?；诮涷炗^察，此表顯示了一些代表值。引起這些潛在因素變更的因素主要有：*IPC協議的使用。用戶模式的IPC協議更快*當系統在CPU高效使用的情況下，時序安排的延遲*對當前blocks服務的logflush其他在AWR報告中，RAC潛在因素多數是從V$GES_STATISTICS中獲得的，并可能對調試非常有效。但無需進行頻繁的監(jiān)控。 note:處理緩存中一致讀(consistentreadCR)block的時間與(buildtime+flushtime+sendtime)—致；處理緩存中當前block請求的時間與(pintime+flushtime+sendtime)—致。5、RAC的等待事件 分析哪些sessions在等待是—個確定時間開銷在哪里的重要方法。在RAC中，等待時間主要歸因于影響獲得實際請求結果的事件上。例如，當在某Instance上的一個session在Globalcache查詢某個block,并不知道是否將收到cache在其他Instance中的data或是是否將獲得從disk上讀取的消息。對于Globalcache的等待事件反映了準確信息并等待全局緩沖block或是messages。它們主要是按照下述進行分類的： *在較廣的分類的概括，被稱作是clusterwaitclass*用占位符代表的臨時事件，主要岀現在block的等待 *當獲得請求結果的精確事件RAC的等待事件對性能分析是非常重要的。它們被應用于ADDM中，從而獲得cachefusion方面的精確診斷。 1）等待事件視圖 對于一個事件的總的等待信息——v$SYSTEM_EVENT —個session的等待事件分類——V$SESSION_WAIT_CLASS —個session等待的事件——V$SESSION_EVENT 這三個視圖匯集了等待時間、meouts和特定事件等待次數。 最近活動的sessions的活動行為——V$ACTIVE_SESSION_HISTORY 每個活動的session最近10個等待事件——V$SESSION_WAIT_HISTORY 活動的sessions正在等待的事件——V$SESSION_WAIT 受到互聯因素影響的一致的SQL語句——V$SQLAREA 這四個視圖用于實時監(jiān)控等待的sessions，包括最近的等待時間歷史信息通過其name和假設的參數，來區(qū)分單個事件自己。對于多數Globalcache等待事件，參數包括文件號、塊號、塊的類型和訪問模式的配置（如held和request模式）在這些視圖中顯示并統計的等待時間在調試相應時間時是非常有用的。注意，等待時間是累積計算的，有最大的該值的不一定就是問題所在。但可用的CPU被占盡或是一個Application的相應時間過長,top等待事件提供了有效的性能診斷信息。note:在V$SQLAREA中使用CLUSTER_WAIT_TIME字段辨別SQL語句受到互聯因素的影響程度，或是在AWRsnapshot上執(zhí)行一個ADDM報告。2Globalcachewaitevent概覽OracleDatabase10g中主要的Globalcache等待事件的簡要描述如下： *gccurrent/crrequest:當一^進程訪問需要一^或者多個塊時，oracle會首先檢查自己的CACHE是否存在該塊，如果發(fā)現沒有，就會先通過globalcache賦予這些塊共享訪問的權限，然后再訪問。假如，通過globalcache發(fā)現這些塊已經在另一個實例的CACHE里面，那么這些塊就會通過CACHEFUSION,在節(jié)點之間直接傳遞，同時出現globalcachecrrequest等待事件。current和cr的不同，如果是讀的話，那就是crrequest，如果是更改的話，那就是currentrequest。 *gc[current/cr][2/3]-way:具體解釋見后面實例 *gc[current/cr]blockbusy:—個current或是crblock被請求并收到，但LMS并沒有立即發(fā)送，因為某些特定的推遲發(fā)送的情況被發(fā)現。 *gc[current/cr]grant2-way:當請求一個block時，receive了一個message，該message應該是賦予了requesterinstance可以訪問這個block。如果這個block沒有在localcache中，則隨后的動作就是去磁盤上讀該block。（插一點別的，oracle的對數據的訪問的控制，是在row級別和object級別但是實際操作的對象卻是block,傳遞的對象也是block，對于一個block，來說，會有一個masterinstance，也就是這個block的管理者，然后還有零到多個參與者，比如有的instance為了讀一致性，可能會在自己的localcache中存著該block的過去某個時間的image，有的instace為了修改該block可能會在自己的localcache中存著該block的pastimage） *gccurrentgrantbusy：當請求一個currentblock時，收到grantmessage。該busy表示請求被阻塞，主要是其他請求在前面或是該請求不能馬上被處理。*gc[current/cr][block/grant]congested：無論是對于current還是cr類型block的請求，block或者grant都獲得了，但是在過程中有擁堵。也就是在內部的隊列中等待超過1msec（納秒） *gc[current/cr][failure/retry]:—個block被請求，卻收到失敗的狀態(tài)或是有其他意外事件的發(fā)生。 *gcbufferbusy:對此，我的理解就是gc的內存不足，有大量的block請求，需要等待將剛剛被pin入內存并使用的blockunpin后再使用。（好像沒理解對，看后面實例吧）3）2-wayblockrequest實例上圖顯示了當一個masterInstance請求一個block該block不在本地cache中時，具體的操作。這里假設masterInstance為SGA1,SGA2中包含了請求的block。具體如下：①SGA1向SGA2直接發(fā)送一個請求，此時，SGA1發(fā)生gccurrentblockrequest等待事件②當SGA2接到請求，它的本地LGWR進程需要flush部分恢復信息到其本地redolog文件中。例如，如果緩沖的block被頻繁的修改，該修改尚未被寫入log中，LMS就需要在傳輸block前令LGWR對log進行flush。這可能會增加一個延遲，可能在請求的node上顯示一個busywait。 ③隨后，SGA2發(fā)送請求的block給SGA1。當該block到達SGA1，等待事件完成，這被反映為gscurrentblock2-way。note:如果R表示在請求者的time，W為消息傳輸的time延遲，S為在server的time。則整個來回的總時間為：R(send)+W(smallmsg)+S(processmsg,pocessblock,send)+W(block)+R(receiveblock) 4)3-wayblockrequest的實例在此，與上一個實例不同的就是block的請求者與block的master、block的緩沖不在同一個node上。所以總體時間為：R(send)+W(smallmsg)+S(processmsg,send)+W(smallmsg)+S(processmsg,processblock,send)+W(block)+R(receiveblock)當遠程讀被掛起，任何在請求Instance上的嘗試讀寫緩沖在buffer中的data的進程將等待gcbufferbusy事件直到block到達。5)2-waygrant實例 6)considered“Lost“Blocks實例如圖，此情況為：在請求的block到達前先收到了sidechannelmessage。在普通環(huán)境中，這是不會發(fā)生的。多數情況下它是轉換問題的顯示或是缺少私有互聯。這常與OS或是網絡的配置問題有關。 note:可嘗試避免此類現象的發(fā)生，通過減小參數DB_FILE_MULTIBLOCK_READ_COUNT的值，使其低于16。 7）Global隊列等待overview隊列等待并不是RAC特有的，但是在RAC環(huán)境中涉及到Globallock的操作。多數對隊列的Global請求是同步的，并且有前臺進程等待。因此，隊列沖突在RAC環(huán)境中更明顯。多數隊列等待發(fā)生在下列類型的隊列: *TX:transaction隊列，用于事務的劃分和追蹤 *TMtable或是partition隊列，用于保護DML執(zhí)行期間table的定義 *HW:高水位線隊列取得用于新的block操作的同步*SQsequence隊列，用于Oraclesequencenumber的序列化增加*USundosegment隊列主要用于自動undo管理（AUM）的特性*TA:主要用于事務恢復的隊列 上述情況下，等待是同時的，可能造成嚴重的序列化，從而導致RAC環(huán)境的惡化。 6、session和system統計使用基于V$SYSSTAT的系統統計使得基于平均的Database描述成為可能。它是很多通過各種工具和方法獲得Database的度量和比率的基礎例如AWR、statspack和Databasecontrol。為了進一步對sessions進行深化的了解,V$SESSTAT視圖是非常有用的。此外，如果使用了MODULE、ACTION模式的統計，將更有效。V$SEGMENT_STATISTICS對于RAC環(huán)境也非常重要，因為它跟蹤了CR的數量以及object當前獲得的blocks RAC相關的統計可以被分為以下幾組：*Globalcacheservice統計：gccrblocksreceived,gccrblockrecevietime等*GlobalEnqueueservice統計：globalenqueuegets等*messages發(fā)送的統計：gcsmessagessent和gesmessagessent可以通過查詢V$ENQUEUE_STATISTICS確定哪個隊列對Databaseservice時間和最終的響應時間有最大的影響。V$INSTANCE_CACHE_TRANSFER顯示了每個block類中有多少current和CRblocks從Instance中接受，包括多少傳輸引起延遲。7、RACtuning的tips 首先，在RAC環(huán)境中，必須先利用傳統的調節(jié)技術對每個Instance進行調節(jié)，此外，下面的內容也很重要：*盡量避免較長的全表掃描來縮小GCS的請求。由GlobalCR請求引起的開支主要是因為當所查詢的結果在本地cache中不存在，先嘗試在其他cache中嘗試找到相應數據。*自動段空間管理可以給tableblocks提供Instance關聯（affinity） *增加sequences的caches改善Instance關聯的通過sequences獲得索引關鍵字的值的性能。*當把range或是list類型的partitioning和data-dependentrouting相結合，可以有效的提高性能。*hashpartitioning可有效降低bufferbusy的沖突，使得buffer訪問分布格局松散，可以使buffers用于更多的并發(fā)訪問。 *在RAC中,brarycache和rowcache操作都是全局協調的。所以過度的解析意味著額外的互聯傳輸。當packages或是procedure需要被重新編譯時，需要以排他模式獲得librarycachelocks。 *因為transactionlocks是全局協調的，在RAC中，也應的到特殊的對待。例如使用tables代替Oraclesequences產生唯一numbers是不推薦的，可能引起嚴重的沖突，即使是在singleInstance系統中。*選擇性不好的indexes不會提高查詢性能，反而會降低DML操作的性能。在RAC環(huán)境中，unselectiveindexblocks可能導致Instance間的沖突，增加cache對indexes傳輸的的頻度。8、indexblock沖突的思考 由于index多數是單調遞增的，往往造成熱塊爭用的問題；而且對于大量的insert操作，可能引起頻繁的splits；所有l(wèi)eafblock的訪問都是通過rootblock的。所以index可能造成性能的降低。對此：*全局索引hashpartitioning*增加sequencecache，如果必要的話9、undoblock考慮當indexblocks包含了從多個Instances發(fā)起的事務被頻繁的讀，過度的undoblock傳輸和undobuffers的爭用經常會發(fā)生。當一個select語句需要讀取一個block，該block正被一個active的事務使用，就不得不用undo來重建一個CR版本。如果block所在的active事務屬于不只一個Instance，則需要結合本地和遠程undoinformation用于一致讀，依據被多個Instances修改的indexblocks的數量和transaction的并發(fā)，undoblock的傳輸可能成為瓶頸。這多發(fā)生在頻繁讀取近期插入的數據但提交不頻繁的應用中。對此應：*使用shortertransaction從而降低這樣的可能性從cache中獲得的indexblock含有未提交的data，從而降低訪問undoinformation用于一致讀的可能 *增加sequencecachesize，從而減少需要進行遠程undo信息組合的需求。10、高水位線的考慮 數據的insert操作是業(yè)務領域的主要功能，新的blocks需要頻繁的分配給segment。如果data的insert操作比率較高，如果沒有找到空閑空間時，需要申請新的blocks。這需要獲得相應的high-watermark（HWM）隊列。因此，最為普遍的狀況為： *較高比率的隊列等待時間enq:HW–contention*較高比率的等待時間對于gccurrentgrantevents前者是HWM隊列序列化的結果，后者是由于當前訪問新的datablocks是需要對新的blocks進行操作。在RAC環(huán)境中，這個空間管理操作的時間長短是與獲得HW隊列和獲得所有新的blocks的Globallocks所用的時間成比例的。這個時間在普通環(huán)境中比較小，因為在訪問新的blocks時是不存在任何沖突的。然而，這種沖突可能會出現在有大量dataload的業(yè)務需求中。對此，建議在本地管理及自動空間管理segments中定義一致的較大的extentsize，從而適當解決相應的問題。11、automaticworkloadrepository 1)overviewAWR是OracleDatabase10g提供的基礎服務工具，用于收集、維護和應用統計信息來檢測問題并進行自我的調節(jié)。AWR主要由兩部分組成：*一個在內存的統計收集設施，由OracleDatabase10g使用并收集統計信息。這些統計被存儲在內存中，可以通過動態(tài)性能視圖查看到(V$)*AWRsnapshots代表了設備的持久部分。可以通過datadictionary視圖和Databasecontrol來訪問。處于以下幾個原因，統計需要保存在永久的設備中：*統計需要用于激活Instancecrashes* —些分析需要歷史數據作為基線的比較*內存的溢出：當由于內存不足，舊的統計數據需要被新的統計數據替換時，可以將舊的統計數據存儲在磁盤上以備后用統計的內存版本由新的后臺進程manageabilitymonitor(MMON)定期的傳輸的disk上。通過AWR，OracleDatabase提供了自動捕獲歷史統計data的方法，無需DBA干涉。2)AWRtablesAWR包括兩類表：*元數據表：用于控制、處理、描述AWR表。例如，OracleDatabase使用元數據表來確定何時執(zhí)行snapshots，并將什么數據捕獲到disk上。此外，元數據包含了snapshots_id和相應通訊時間之間的映射。*歷史統計表：存儲了OracleDatabase的歷史統計信息。每個snapshots就是在特定時間點捕獲的內存中的Database統計數據。AWR表的names都有一個WRx$前綴，其中x指明了tables的種類：*WRM$表存儲了AWR中的元數據 *WRH$表中存儲了歷史數據和snapshots可以是使用字典視圖來查詢AWR數據。在AWR中任何相關的歷史信息