LOGFILESYNC概述（第一篇）-創(chuàng)新互聯(lián)

成都創(chuàng)新互聯(lián)公司堅持“要么做到，要么別承諾”的工作理念，服務領(lǐng)域包括：網(wǎng)站制作、成都網(wǎng)站制作、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務，滿足客戶于互聯(lián)網(wǎng)時代的寧明網(wǎng)站設計、移動媒體設計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡建設合作伙伴！

曾經(jīng)有將近半年的時間，我都在跟log file sync打交道，每次查看系統(tǒng)壓測期間的TOP 5等待事件，log file sync都穩(wěn)穩(wěn)的排在第一的位置，而且平均響應時間已經(jīng)達到了10ms，隨著一步步的優(yōu)化，系統(tǒng)壓測的TPS從剛開始時候的4000到6000到8000，TPS提升的過程也是對log file sync等待事件優(yōu)化的過程。本章主要介紹log file sync相關(guān)的原理和優(yōu)化技巧，希望本章的內(nèi)容能或多或少的幫助到你。

  log file sync的產(chǎn)生背景

在事務提交時，Lgwr需要把事務產(chǎn)生的日志刷新到磁盤以實現(xiàn)持久化，做到ACID的D的要求，前臺進程從發(fā)出提交指令到接受到Lgwr進程日志寫完成的通知，這整個過程都會等待log file sync等待事件。前臺進程在等待log file sync的過程中是被阻斷的，不能做其它事，當Lgwr刷新日志到在線日志后會通知前臺進程日志寫完成，前臺進程接受到通知后，繼續(xù)做其它事。日志一旦被刷新到磁盤標志著事務持久化的結(jié)束，通過日志來實現(xiàn)事務的持久化已經(jīng)成為各個數(shù)據(jù)庫的通用準則，之所以用日志來實現(xiàn)事務的持久化，速度快是最重要的一個原因，我們可以想象一個事務對一個具有3個索引表上插入10個記錄，如果是通過刷新數(shù)據(jù)臟塊來持久化，需要刷新多少個數(shù)據(jù)塊，由于堆表的特性，10個記錄可以認為是聚集在1個數(shù)據(jù)塊上，但是10個記錄針對索引，非?？赡艿乃饕龎K數(shù)能有二三十個，因為索引是有序的，不像堆表可以對記錄不加區(qū)分的聚集在一起，當然使用了ASSM管理后，插入記錄的時候，會根據(jù)進程的pid做hash去選擇插入的數(shù)據(jù)塊，因此一定程度上，對于10條記錄，如果是多個進程所插入，也非常有可能是在不同的數(shù)據(jù)塊中，不過我們這里說的是一個事務，當然指的就是一個進程了。按照我們的推算的話，我們僅僅是插入了10條記錄，但是涉及到的臟塊可能有30個左右，每次事務提交都需要刷新離散的30個數(shù)據(jù)塊，這個性能實在是太低了，而日志在磁盤是有序的，因此刷新效率上要高出很多，日志還為數(shù)據(jù)庫實現(xiàn)其他功能提供了基礎，例如提供實例突然down機后的實例恢復，為實現(xiàn)日志挖掘提供了基礎，為備庫的恢復提供了基礎等等。

log file sync是Oracle數(shù)據(jù)庫中最普遍的等待事件之一，一般log file sync的等待時間都非常短 1-8ms，這個時間取決于你數(shù)據(jù)庫的硬件配置、主機的負載情況等等，一般情況下把日志盤放在高端存儲上，log file sync的時間應該能維持在1-5ms之間，如果使用的是pc，有raid卡的話，log file sync的時間應該能維持在3-15ms，但是這些數(shù)據(jù)并不絕對，還要依據(jù)你數(shù)據(jù)庫的配置和負載情況來定，例如我曾經(jīng)遭遇過在把日志放在本地盤，raid卡的cache有512m，log file sync接近30ms的情況，后面經(jīng)過分析是由于日志寫入量和臟數(shù)據(jù)塊的寫入量太大，導致raid卡的cache有被擊穿的問題，而且當時并沒有關(guān)閉raid卡的讀cache，保留的默認的7:3的讀寫比例，一般如果使用的不是raid 5等需要做校驗的raid設置例如raid 1或raid10，都可以把raid卡的cache策略全部用于寫cache。但是對于存儲就不能這么搞了，不能夠把讀cache全部關(guān)掉，只用作寫cache，因為相對于raid卡的cache來說，本身的cache大小都比較小，所以就顯得特別寶貴，但是存儲的cache一般都比較大，例如一個中斷存儲的機頭cache也能夠8G或者16G，他們一定程度上既可以用作寫cache，又是對于主機內(nèi)存的一個延續(xù)。

log file sync等待事件的P1，P2，P3參數(shù)的含義：

·  P1 ： buffer# ，log buffer中buffer的編號

·  P2，P3 未使用

產(chǎn)生log file sync的場景，常見有以下幾種：

·  commit操作

·  rollback操作

·  DDL操作（DDL操作實施前都會首先進行一次commit）

·  DDL操作導致的數(shù)據(jù)字典修改所產(chǎn)生的log file sync

·  某些能遞歸修改數(shù)據(jù)字典的操作：比如查詢SEQ的next值，可能會導致修改數(shù)據(jù)字典。一個典型的情況是，SEQ的cache屬性設置為nocache，那么會導致每次調(diào)用SEQ都要修改數(shù)據(jù)字典，產(chǎn)生遞歸的log file sync。

一個正常的系統(tǒng)里，絕大多數(shù)的log file sync等待都應該是commit操作造成的log file sync等待，某些異常的系統(tǒng)，比如頻繁的rollback、seq的cache設置為nocache的系統(tǒng)，也可能會造成比較多的log file sync等待。

當前文章：LOGFILESYNC概述（第一篇）-創(chuàng)新互聯(lián)
網(wǎng)頁路徑：http://muchs.cn/article4/ddjiie.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供微信公眾號、網(wǎng)站設計公司、網(wǎng)站改版、電子商務、App開發(fā)、外貿(mào)建站

廣告

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