LOGFILESYNC概述（第五篇）

其他組建的調(diào)優(yōu)

log file sync問題的解決是一個(gè)系統(tǒng)工程，除了上面一節(jié)描述的調(diào)優(yōu)方式，我們看看對(duì)于其他組建是否也需要調(diào)優(yōu)。例如commit本身作為一個(gè)redo record也是需要被拷貝進(jìn)log buffer的，如果此時(shí)log buffer太小沒有了空間，那么豈不是也會(huì)在一定程度上影響提交的效率，再如，Lgwr在刷新日志前，需要確認(rèn)所有分配過空間的buffer都已經(jīng)拷貝結(jié)束，如果發(fā)現(xiàn)還有進(jìn)程在持有redo copy latch就說明還有進(jìn)程正在往log buffer拷貝日志，那么這個(gè)時(shí)候也會(huì)導(dǎo)致提交變慢。

公司主營(yíng)業(yè)務(wù)：做網(wǎng)站、網(wǎng)站建設(shè)、移動(dòng)網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競(jìng)爭(zhēng)能力。創(chuàng)新互聯(lián)是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對(duì)我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)推出石柱土家族免費(fèi)做網(wǎng)站回饋大家。

LOG BUFFER 的調(diào)優(yōu)

10G以后，LOG BUFFER一般情況下已經(jīng)比較大，一般為1到多個(gè)granules大小，除非你看到了比較多的log buffer space等待事件，否則不需要調(diào)整log buffer的大小。

redo相關(guān)latch的調(diào)優(yōu)
l redo copy latch：僅僅用來跟蹤是否有進(jìn)程正在往log buffer里拷貝數(shù)據(jù)。lgwr在真正開始寫之前，必須等待相關(guān)的進(jìn)程拷貝完畢，在此期間,lgwr會(huì)等待LGWR wait for redo copy等待?？梢酝瑫r(shí)向log buffer里進(jìn)行拷貝的進(jìn)程的數(shù)量由_log_simultaneous_copies決定。除非觀察到明顯的redo copy latch等待，否則保持默認(rèn)值。

l redo allocation latch：保護(hù)進(jìn)程在redo buffer里分配空間時(shí)使用，保證各個(gè)進(jìn)程間彼此分配的空間不重疊。9.2版本以前由于redo allocation latch只有一把，因此比較容易引起此latch的真用，9.2版本以后，根據(jù)主機(jī)CPU的多少，log buffer已經(jīng)被拆分成多個(gè)子LOG BUFFER，每個(gè)子buffer 都有有對(duì)應(yīng)的redo allocation latch，很大程度上緩解了redo allocatoin latch的爭(zhēng)用，除非看到了明顯的redo allocation latch的爭(zhēng)用，否則不用調(diào)整log buffer的數(shù)量。10G以后，私有redo和IMU的出現(xiàn)，每一個(gè)私有redo都由一個(gè)私有的redo allocation latch保護(hù)，進(jìn)一步降低了redo allocation latch的爭(zhēng)用。

 redo writing latch：這個(gè)latch保護(hù)的是一個(gè)標(biāo)志位，進(jìn)程獲取這個(gè)latch后，修改標(biāo)志位，比如把0改為1，代表lgwr正在寫，這樣后續(xù)的提交進(jìn)程，獲得這個(gè)latch后讀取標(biāo)志位，就知道當(dāng)前LGWR是不是正在寫了，避免了很多不需要的重復(fù)通知。


一般是不需要的，除非他們相關(guān)的等待已經(jīng)引起了你的注意，而且ORACLE各個(gè)版本也一直在優(yōu)化相關(guān)的latch的獲取和釋放，比如redo allocation latch，這一塊已經(jīng)做的非常高效了。

新的調(diào)優(yōu)手段

10G之前，在事務(wù)做提交的時(shí)候，必須等待Lgwr刷日志完成才能繼續(xù)做其它事，也就是說必須符合事務(wù)持久化的條件，可能學(xué)過其他數(shù)據(jù)庫(kù)的同學(xué)學(xué)ORACLE的時(shí)候怪怪的，因?yàn)橄馦ySQL、MongoDB等數(shù)據(jù)庫(kù)都支持對(duì)日志的異步刷新，我想之所以O(shè)RACLE這么晚才推出這一功能，主要還是使用ORACLE的客戶都是金融、證券等行業(yè)巨多，這些行業(yè)對(duì)于數(shù)據(jù)的丟失是零容忍的，因此他們對(duì)此并無需求，直到10GR1，ORACLE公司才默默的推出了一個(gè)參數(shù)：commit_logging，這個(gè)參數(shù)可以實(shí)現(xiàn)讓事務(wù)在提交時(shí)，并不同步刷新日志，而是在合適的時(shí)候去觸發(fā)，這個(gè)參數(shù)可以有四種組合：

commit write [batch|immediate][wait|nowait]

10GR2版本發(fā)布的時(shí)候，這個(gè)參數(shù)被拆成了2個(gè)參數(shù)，commit_logging，commit_write，個(gè)人認(rèn)為10GR2拆分后的參數(shù)，更能準(zhǔn)確表達(dá)參數(shù)的意圖。我們先著重的看下commit_write這個(gè)參數(shù)，它的參數(shù)值可以為wait/nowait，代表：前臺(tái)進(jìn)程在進(jìn)行事務(wù)提交的時(shí)候，通不通知LGWR去刷新日志。wait為通知，前臺(tái)進(jìn)程會(huì)等待log file sync。nowait為不通知，僅僅等待其他操作觸發(fā)lgwr去寫日志（如3秒，1M大小，1/3滿）。如果你的業(yè)務(wù)對(duì)數(shù)據(jù)的一致性的要求不高，對(duì)ACID的D沒有要求，為了提高事務(wù)數(shù)、提高性能，你可以選擇commit_write為nowait方式。而在10G以前，ACID的D是必須滿足的，也就是說，前臺(tái)進(jìn)程在提交的時(shí)候，必須要等待LOG FILE SYNC，等待LGWR刷新日志到磁盤。我們?cè)賮砜聪耤ommit_logging參數(shù)，參數(shù)可以選擇的值有batch/immediate，這個(gè)參數(shù)極其容易引起人的誤解，讓人誤以為batch的含義是，控制著事務(wù)是否以group commit的方式打包提交，而immediate含義是讓事務(wù)一個(gè)個(gè)的提交，一次提交刷新一次log buffer，但實(shí)時(shí)不是這樣的！
immediate與batch相比，commit的改變向量（修改回滾段頭的事務(wù)槽）將作為stand alone（單獨(dú)的）的redo record產(chǎn)生，跟9I的commit記錄日志的方式是一樣的。batch 模式下commit改變向量的記錄方式是合并進(jìn)事務(wù)產(chǎn)生的change vector里，作為一個(gè)redo record,這個(gè)batch模式依賴是否使用私有redo和IMU，如果私有redo和IMU被關(guān)閉的情況下，batch的設(shè)置也就沒了作用。

我們對(duì)insert into a values(1111);commit;來進(jìn)行dump log file，闡述一下batch/immediate方式的區(qū)別 :

DUMP LOG FILE：?jiǎn)⒂盟接衦edo和IMU，設(shè)置commit_logging為immediate，commit的日志作為單獨(dú)的redo record產(chǎn)生，一共2條redo record，第二個(gè)redo record為commit產(chǎn)生的，見加粗部分(OP:5.4,代表為UNDO段頭的修改）

REDO RECORD - Thread:1 RBA: 0x00044d.00000002.0010 LEN: 0x0230 VLD: 0x05
SCN: 0x0000.041b921c SUBSCN:  1 06/25/2013 11:27:32
(LWN RBA: 0x00044d.00000002.0010 LEN: 0002 NST: 0001 SCN: 0x0000.041b921c)
CHANGE #1 TYP:0 CLS:51 AFN:3 DBA:0x00c04c80 OBJ:4294967295 SCN:0x0000.041b91d1 SEQ:1 OP:5.2 ENC:0 RBL:0
ktudh redo: slt: 0x0016 sqn: 0x00002bee flg: 0x0012 siz: 136 fbi: 0
            uba: 0x00d1a78d.0068.2c    pxid:  0x0000.000.00000000
CHANGE #2 TYP:2 CLS:1 AFN:9 DBA:0x024002c5 OBJ:15750 SCN:0x0000.041b916a SEQ:1 OP:11.2 ENC:0 RBL:0
.......省略

REDO RECORD - Thread:1 RBA: 0x00044d.00000004.0010 LEN: 0x00d0 VLD: 0x05
SCN: 0x0000.041b921e SUBSCN:  1 06/25/2013 11:27:34
(LWN RBA: 0x00044d.00000004.0010 LEN: 0001 NST: 0001 SCN: 0x0000.041b921d)
CHANGE #1 TYP:0 CLS:51 AFN:3 DBA:0x00c04c80 OBJ:4294967295 SCN:0x0000.041b921c SEQ:1 OP:5.4 ENC:0 RBL:0
ktucm redo: slt: 0x0016 sqn: 0x00002bee srt: 0 sta: 9 flg: 0x2 ktucf redo: uba: 0x00d1a78d.0068.2c ext: 104 spc: 2050 fbi: 0


DUMP LOG FILE：?jiǎn)⒂盟接衦edo和imu，設(shè)置commit_logging為batch，commit作為一個(gè)改變向量合并進(jìn)了事務(wù)的redo record里，作為一條redo record，change #3為commit產(chǎn)生的。

REDO RECORD - Thread:1 RBA: 0x00044d.00000002.0010 LEN: 0x0230 VLD: 0x05
SCN: 0x0000.041b921c SUBSCN:  1 06/25/2013 11:27:32
(LWN RBA: 0x00044d.00000002.0010 LEN: 0002 NST: 0001 SCN: 0x0000.041b921c)
CHANGE #1 TYP:0 CLS:51 AFN:3 DBA:0x00c04c80 OBJ:4294967295 SCN:0x0000.041b91d1 SEQ:1 OP:5.2 ENC:0 RBL:0
ktudh redo: slt: 0x0016 sqn: 0x00002bee flg: 0x0012 siz: 136 fbi: 0
            uba: 0x00d1a78d.0068.2c    pxid:  0x0000.000.00000000
CHANGE #2 TYP:2 CLS:1 AFN:9 DBA:0x024002c5 OBJ:15750 SCN:0x0000.041b916a SEQ:1 OP:11.2 ENC:0 RBL:0
CHANGE #3 TYP:0 CLS:51 AFN:3 DBA:0x00c04c80 OBJ:4294967295 SCN:0x0000.041b921c SEQ:1 OP:5.4 ENC:0 RBL:0
ktucm redo: slt: 0x0016 sqn: 0x00002bee srt: 0 sta: 9 flg: 0x2 ktucf redo: uba: 0x00d1a78d.0068.2c ext: 104 spc: 2050 fbi: 0


個(gè)人感覺commit_logging參數(shù)的作用不大，可能有助于減少ACID的異常時(shí)間，對(duì)日志量的size在batch模式下有輕微的減少。

本文標(biāo)題：LOGFILESYNC概述（第五篇）
本文地址：http://bm7419.com/article12/pcihdc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供小程序開發(fā)、網(wǎng)站設(shè)計(jì)、標(biāo)簽優(yōu)化、網(wǎng)站改版、網(wǎng)站排名、外貿(mào)建站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)

外貿(mào)網(wǎng)站建設(shè)