關(guān)于在極高負(fù)荷下Oracle redolog搭配的一些建議
在Oracle數(shù)據(jù)庫的現(xiàn)有系統(tǒng)構(gòu)造下，redolog擔(dān)負(fù)了很大的壓力。這是因?yàn)樗刑峤唤o數(shù)據(jù)庫的交易都必需在commite確認(rèn)前穿越LGWR歷程將相干消息寫入redolog，而一個oracle實(shí)例只有一個LGWR歷程，并且在UNIX系統(tǒng)上該歷程是一個單線程過程，所以能運(yùn)行在一個內(nèi)核上。在前期的主機(jī)系統(tǒng)上這個問題并不嚴(yán)重，然而隨著多內(nèi)核/多線程技巧的進(jìn)展，現(xiàn)在曾經(jīng)有了能夠扶持128個內(nèi)核/256個線程的主機(jī)，而且扶持更多內(nèi)核和線程的主機(jī)即刻揭示，這個問題將出現(xiàn)得更加深重。
你遐想一下如收獲景，就能夠感受到LGWR歷程的境地：有一個水池（redolog），只有一個人(LGWR)能夠把水桶(transsion)里的水(transsion data)倒進(jìn)去，這個人的邊上站了127個人(server processor)不時的爭相把手中的水桶(transsion)交到他的手中。
固然我們很憐惜這個晦氣的老兄，然而由于oracle這個黑心的老板不甘心給它加派人手，我們也只好想想其它措施來加快他的工作速度了，例如強(qiáng)勁一下他的體格可能改革一下水池構(gòu)造，讓他工作起來迅捷一點(diǎn)。本文即便談?wù)撊绾巫孡GWR歷程工作起來更管用率。
由于現(xiàn)在的主機(jī)不扶持不同型號的CPU混用，因而給他吃獨(dú)食（用高功能CPU運(yùn)行該歷程）是不可能了。然而我們能夠讓壟斷系統(tǒng)的歷程調(diào)動過程給它開小灶，讓它的運(yùn)行優(yōu)先級比其它oracle歷程高，可能寬暢把它設(shè)為實(shí)時歷程，讓他盡量不受壟斷系統(tǒng)歷程調(diào)動的波及，盡也許多地挪借CPU工夫，從而到達(dá)讓它多干活的目標(biāo)。
那么如何改革水池（也即便redolog文件）呢？其實(shí)很容易，即便把它放到最快的存儲裝備上就行了。
內(nèi)存毫無疑問是全副計(jì)算機(jī)系統(tǒng)中我們能夠設(shè)置的最快存儲裝備，穿越memory FS可能ramdisk軟件，我們就能夠在系統(tǒng)的內(nèi)存空間中分出一局部來存儲redolog文件。這個措施乍看起來確乎不錯，我們所必需付出的即便多買點(diǎn)內(nèi)存。然而精細(xì)想想，就會感受有問題了。為什么呢？萬一主機(jī)或主機(jī)上ti.tianan-tep.com的軟件（如:壟斷系統(tǒng)/數(shù)據(jù)庫/利用）揭示問題導(dǎo)致系統(tǒng)crash，oracle數(shù)據(jù)的全面性就沒法保證了。因而我提倡，除非你的系統(tǒng)是拿來演示系統(tǒng)功能的，如TPCC測驗(yàn)，就不要利用這個措施。
另外一個抉擇的可靠性就強(qiáng)多了，速度也很不錯，惋惜即便一個字：貴！好在支撐如此宏偉和忙碌的業(yè)務(wù)系統(tǒng)的用戶確定不缺錢，因而該當(dāng)問題不大。廢話說了許多，答案究竟是什么？cache LUN!現(xiàn)在市場上有一些廠商（如惠普/HDS）的***級磁盤陣列扶持在它的內(nèi)部cache中劃一局部出來存儲一些對速度要求極高的數(shù)據(jù)，這局部的CACHE在主機(jī)看來和等閑磁盤空間未曾差異，然而由于這些數(shù)據(jù)是存在磁盤陣列的cache里，無須要寫入物理硬盤，因而功能奇快。至于數(shù)據(jù)的平安性，由于高端存儲都有專程的電源設(shè)計(jì)用來保證即便表面電源斷電，CACHE中的數(shù)據(jù)也不會失落，加上這些存儲的扼制軟件可靠性極高，大約上不存在軟件crash的可能性co.cosibo.com.cn，因而該當(dāng)能夠塌心。
萬一很不幸，你的老板是既要馬兒跑又要馬兒不吃草的主，不甘心出錢利用cache LUN，那就只能盡量利用良好的存儲裝備，然后琢磨它的手冊，把這個存儲的每一滴血都榨出來。一個必需當(dāng)心的事項(xiàng)是存儲redolog的裝備盡量不要與存儲數(shù)據(jù)庫其它文件的裝備互相擾亂。萬一可能，良好把redolog和其它文件放在不同的存儲裝備上。
關(guān)于極高負(fù)荷情形下的Oracle redolog的問題就介紹到這里，希望通過本次的介紹能夠帶給您一些收獲，謝謝了！
【編輯推薦】
分享到微信 
分享到微博
