oracle學習筆記 Oracle日誌原理剖析
一）一致性和性能
日誌是所有數據庫的一個很核心的內容很重要
它關係到數據庫的數據的一致性
目前大家在使用的我們可看到的有幾個數據庫
有oracle、sqlserver、mysql、db2還有以前的sybase
這所有的數據庫它們的日誌原理幾乎都一樣
綜觀現在在用的數據庫基本內容上是基本一樣的
都由最基本的關係數據表組成
都用sql基本語法進行各種庫主體數據的操作
基本的不同產生於對這些基本功能的執行上
自己有自己的實現方法和代碼
高級功能的不同主要產生在對一致性的保護和對性能的提升
對基本功能組合或添加一些額外功能也會產生其它一些屬於自己的高級功能
其實這些各種功能它們的原理也是基本相同的
區別也只在實現方法和代碼
在數據庫體積來講
小的數據庫在高級功能方面會有所刪減
大的數據庫會有更多隻屬於自己的高級功能
另外一個比較明顯的區別是應環境產生的
數據庫可使用的操作系統類型越多其適應性越強
細看所有功能類似的軟件
功能基本也是類似的
使用過並且熟悉了以後會發現最大的區別只是在外觀
但它們在市場上處於競爭狀態，競爭用戶的使用和資金
日誌和性能沒有多大關係
但是日誌和數據庫的數據的一致性關係非常大
一個軟件其它方面沒有變動的情況下
在提高它的性能的時候
一定會損失掉一部分穩定性
軟硬件都是如此
你盲目的給cpu超頻，就很容易造成系統的崩潰
爲了提高硬盤的寫入速度，有人採取減少數據效驗的辦法
如有些格式的音頻視頻文件爲了讓它傳輸的更快而不進行數據效驗
這些文件在進行了多次網絡傳輸後多數都已經損壞了
在網絡上爲了讓網絡視頻播放的更快
在不斷的降低視頻的分辨率而視頻越來越模糊
想讓數據庫處理數據的速度更快，相同的環境下也只能降低對數據正確性的保護
但是oracle很少有人提起如何提高它的性能只是講如何優化它
對本人來講想了很長時間也沒想到在它內部怎麼直接提高它的性能
可能因爲oralce是個成熟的軟件
內部的各方面組合已經進行了最大的平衡
對一個方面提高性能往往會影響其它方面的性能
所以不能說要它提高性能
能做的只有統觀全局進行相對當前軟硬件配置的最平衡的優化
對oracle在網絡上有一些提高性能的方法
如直接提高硬件的性能，相同硬件的性能肯定是以喪失穩定性爲代價的
而且一般性能只能在一定範圍內提升，想更多的提高反而適得其反
舉一個明顯的例子
你可以在分配內存的時候把內存都分配給oracle
但是這時操作系統就沒有內存了，操作系統崩潰oralce也沒法運行了
對oracle軟件方面的性能提升，都集中在所執行的客戶程序的編寫上
主要讓客戶編寫程序時更符合oracle軟件環境
讓客戶程序執行的更快更安全
一個針對優化過的程序性能會遠遠高於不符合oracle運行環境的程序
這就要求程序員對oracle基本結構和功能非常的熟悉
以最佳的方式選擇oracle組件及功能的使用
它沒有改變數據庫，只是讓客戶程序最優化的使用oracle數據庫
再次提出直接對oracle提升性能是有風險的
一旦錯誤就會造成數據的丟失，
而且用這個軟件的用戶數據往往都是非常重要的
哪怕丟失一個字節都有可能造成巨大的損失
所以選擇的時候，還是一致性重要
我們知道對oracle數據庫或者說對任何數據庫來講
我們學習的重點無非就是兩個
第一個就是數據庫的數據的一致性
這個我們要保障特別是對dba
所以我們要研究它而且是我們深入研究的課題
大家聽完老師整個體系的課以後
大家會對數據庫的一致性應該說有非常深的瞭解
不會出現一些因爲誤操作而產生的數據的一致性的問題
這個老師相信肯定沒有問題
另外就是我們讓oracle運行的更快
這是我們學習的第二個目標
這兩個目標如果都很熟的話
別人一提數據庫的一致性的話你有一整套的理論體系來支撐你
優化的時候也有一整套的理論體系和相關的一些實踐來支撐你
這說明你oralce學的不錯了
所以說學oracle不要看我們學了這麼多的內容
最終還是糾結到兩大塊
第一是一致性
第二就是數據庫的性能
oracle日誌只是和一致性有關係和性能沒有什麼關係
講到這個地方給大家強調一下，接下來學日誌的時候就有相關的側重點了
oracle的數據庫的一致性從某種意義來講重要性要遠遠的高於oracle的性能
數據庫可以慢一些，但是數據的一致性一定不能出問題
這是個原則性問題
我們從一開始講到最後一節課的時候
中間都會穿插着一些關於數據庫一致性問題
我們講oracle任何一個知識環節的時候都會涉及到它
特別從日誌開始講了以後
以後數據庫的一致性問題會持續的給大家灌輸給大家去講
二）oracle日誌的原理
講了日誌的原理以後大家就知道oracle爲什麼需要日誌了
oracle數據庫啓動後
有一堆dbf文件對應內存中的buffercache
內存中還有logbuffer對應磁盤中的redolog日誌
客戶的sql語句進入數據庫以後要執行
而對oracle數據庫來講是有非常多的連接過來
每個連接會有大量的sql語句
就是數據庫在同一時間點會有大量的sql語句在執行
sql語句有查詢的有增加的有刪除的有修改的
這就是我們常說的增刪改查
我們先不關心這些
1）史記講解法
buffercache裏面有一堆的buffer
我們這麼來理解oracle日誌產生的過程
假設在buffercache上站着一個人
它能夠看到buffercache裏面所有的buffer
而且這個人眼睛非常的快
我們來看buffercache的狀態
對buffercache來講大量的sql語句執行
在一個時間點其中的一個buffercache中的buffer塊給改了
在下個時間點另一個buffercache塊給改了
這兩個時間點差了幾毫秒或幾微秒
在另外時間點其它的buffer塊給改了
就是說在一個時間段內buffercache裏面有大量的buffer被修改
然後這個人就拿着一個本在記錄
嚴格的按照時間來記錄buffer的一個改變過程
比如在一個時間段
一個buffer給改了，它馬上看到了，看到以後，馬上在日記本里面記下來
記下來這個buffer在那個時間點發生了什麼改變
剛記完以後又一個buffer給改了
馬上在日誌裏面在本里面記上在這個時間點那個buffer發生什麼樣的改變
也就是這個人
以極快的速度嚴格的按照時間順序來記錄buffer的一個改變歷程
這些日誌會記錄到logbuffer裏面去
最後logbuffer會通過LGWR這個進程寫到磁盤上的redolog裏面去
先寫第一個redolog
第一個redolog寫滿以後再寫第二個然後再寫第三個
好我們再來回顧一下
日誌的記錄過程，日誌的產生的過程就這麼認爲
在buffercache上面有一個人
拿着一個小本
這個人眼睛非常快，記錄的非常快
它能夠看到buffercache裏面所有的buffer
這個人就嚴格的按照時間順序來記錄buffercache裏面的所有的buffer的一個改變過程
也就是說
我們的日誌記錄的是buffer的改變，並且按照時間順序記錄的
這個人就幹這麼一件事情
在記錄buffer改變的時候
它不關心是哪個會話上來哪個sql語句修改的誰
它只關心哪個buffer改變了
所以說日誌裏面記錄的就是buffer裏嚴格的按照時間順序記錄的buffer的整個改變過程
這個人我們可以叫史學家
我們知道歷史上有叫史學家的角色
它天天跟在皇上的身邊
皇上的一言一行、一舉一動每一個決策他都會記錄下來
這個史學家是用來約束皇上的
他嚴格的、實事求是的去記
它並不去帶着任何個人感情色彩
皇上做着的任何一件事情記錄下來
皇上的整個的一個人生按照時間的軌跡去記錄
這是我們講通過史學家的一個例子
來講日誌的產生過程
講完以後就是用一句話來概括
oracle的日誌是嚴格的按照buffercache裏面的buffer的改變的時間去記錄的
首先日誌記錄的是buffer的改變，第二它嚴格的按照時間去記錄的
我們用兩句話可能更好一些
第一日誌記錄的是buffer，日誌是以buffer爲單位來記錄的
第二是按照buffer它改變的時間順序來記錄的
也就是這個史學家在上面不停的看哪個buffer改了馬上記
先這麼認爲就可以了
這就是日誌
我們後面講的時候慢慢就理解一些oracle記錄日誌的一些記錄方式
這對以後學習非常的有幫助
這是我們通過 史記講解法 來講解
2）日誌記錄方式
我們知道日誌記錄方式是以buffer來記錄的
它到底怎麼記錄的呢
比如buffercache裏面的一個buffer改變了
記錄buffer的改變有很多種方式
oralce要記錄這個buffer的改變
第一、記錄buffer的地址也就是磁盤中數據塊的地址
第二、時間點，哪個時間改變的
第三、對這個數據塊做了什麼改變
如數據塊改變是做了insert改變還是做了delete改變
還有insert插入的數據是什麼
做了delete刪除的數據是什麼
對數據塊的改變無非就是增加數據和刪除數據
另外修改數據對buffer來講就是刪除一行數據然後再插入一行數據
是把這一行先delete然後再insert然後組成一個update
比如我們執行了一個delete的sql語句
它刪除了一萬行
這一萬行在一千個塊裏面
這時我們就可以大體粗略的認爲oracle產生了一千條日誌
因爲針對每一塊都產生一條日誌
這就是日誌產生的方式
日誌裏面有數據塊的地址、改變的時間、還有是怎麼改變的
怎麼改變就是增刪
還有隻改了一行數據但是產生了幾十k的日誌
這很有可能
所以oracle的日誌的產生的量還是很大的
以後我們還會去研究：
oracle的日誌到底產生的量是多大
oracle日誌的產生會不會產生性能問題
日誌對性能的影響
在oracle的等待事件wait events會有涉及
日誌對性能一般沒有影響
對oracle數據庫的修改會產生大量的日誌
這個日誌需要從logbuffer到redolog
到redolog就涉及到IO
有IO就可能有性能問題
這是日誌記錄方式
也講了oracle日誌工作會產生大量的日誌
三）實際日誌產生過程
實際的日誌產生的過程裏面會有一些性能的問題
老師在課程中畫了不少圖
他的圖很隨意但是應該說是有含義比較有意義
學生本人沒有把他的圖也畫下來是因爲只想用文字來記述課程
內存有sharedpool，
buffercache、logbuffer對應磁盤上的dbf和redolog
oracle實例連接很多客戶會話
每一個會話都分到一個一小塊內存，這塊內存叫PGA
客戶會話oracle用server process處理，每個serverprocess都會產生一個PGA
都有可能修改buffercache中的一個buffer
server process會將磁盤block塊讀到buffer裏面去
會從內存buffer裏面讀數據到cpu裏面去
也會修改buffer的數據
所有的這些訪問都是serverprocess來做的
當然髒數據塊寫回的時候是使用的DBWR進程
serverprocess每修改一次buffer的時候它會自己產生日誌
先寫到自己的PGA裏面去
當寫到一定的程度的時候，它再從PGA寫到logbuffer裏面去
第二個serverprocess也一樣
當它修改某個buffer的時候它也會產生日誌
也會從PGA寫到logbuffer裏面去
實際的日誌產生的過程
是serverprocess修改buffer產生日誌寫到自己的PGA裏面去
在某些觸發的條件下
會把日誌寫到logbuffer裏面去
logbuffer最終又通過進程LGWR寫到磁盤的redolog裏面去
這就是實際的日誌產生的過程
2016年10月27日
文字：韻箏