SQLITE中原子提交的实现
轉自：http://blog.csdn.net/LocalVar/archive/2008/02/13/3620555.aspx
?
1.??? 引言
像SQLITE這樣支持事務的數據庫的一個重要特性是“原子提交”。原子提交意味著，一個事務中的所有修改動作要么全都發生，要么一個都不發生。有了原子提交，對一個數據庫文件不同部分的多次寫操作，就會像瞬間同時完成了一樣。當然，現實中的存儲器硬件會把寫操作串行化，并且寫每個扇區都會花上那么一小段時間，所以，絕對意義上的“瞬間同時完成”是不可能的。但SQLITE的原子提交邏輯還是讓整個過程看起來像那么回事。
SQLITE保證，即使事務執行過程中發生了操作系統崩潰或掉電，整個事務也是原子的。本文描述了SQLITE實現原子提交時所采用的技術。
2.??? 對硬件的假設
雖然有的時候會使用閃存，但下文中，我們將把存儲設備稱為“磁盤”。
我們假設對磁盤的寫操作是以“扇區”為單位的，也就是說不可能直接對磁盤進行小于一個扇區的修改，要想進行這類修改，你必須把整個扇區讀進內存，進行所需的修改，然后再把整個扇區寫回去。
對真正“磁盤”來說，讀寫操作的最小單位都是一個扇區；但閃存有些不同，它們的最小讀單位一般遠小于最小寫單位。SQLITE只關心最小寫單位，所以，在本文中，我們說“扇區”的時候，指的是向存儲器中寫數據時的最小數據量。
3.3.14版之前，SQLITE在任何情況下都認為一個扇區的大小是512字節，有一個編譯期選項能改變這個值，但從未有人用更大一些的值測試過相關代碼。直到不久以前，把這個值定為512都是合理的，因為所有的磁盤驅動器都在內部使用512字節的扇區。但最近，有人把磁盤扇區的大小提升到了4096字節，而且，閃存的扇區一般也是大于512字節的。由于這些原因，從3.3.14版開始，SQLITE的操作系統接口層提供了一種可以從文件系統獲取真實扇區大小的方法。不過，到目前為止（3.5.0版），這一方法仍然只是返回一個硬編碼的512字節，因為不論是win32系統還是unix系統，都沒有一個標準的機制來獲得實際的值。但這種方法給了嵌入式設備的提供商們根據實際情況進行調整的能力，也讓我們未來在win32和unix上給出一個更有意義的實現成了可能。
SQLITE并不假設對扇區的寫操作是原子的，它僅假設這種寫是“線性”的。所謂線性是指：寫一個扇區時，硬件總是從扇區一端開始，一個字節一個字節的寫到另一端結束，中間不會后退，硬件可以從頭向尾寫，也可以從尾向頭寫。如果掉電發生時只寫到了扇區的中間，則可能出現扇區一部分修改了而另一部分沒被修改的情況。SQLITE在這里做的一個關鍵假設是：只要扇區被修改了，那么它的第一個字節和最后一個字節中的至少一個會被修改，也就是說，硬件絕不會從中間開始向兩端寫。我們不清楚這個假設是否總是對的，但它看起來是合理的。
在上一段中，我們說“SQLITE沒有假設寫扇區是原子的”。默認情況下，這是正確的，但在3.5.0版中，我們增加了一個叫做“虛擬文件系統（VFS）”的接口，它是SQLITE和底層文件系統通訊的唯一路徑。代碼中包含了用于unix和windows的默認VFS實現，同時提供了一種在運行時創建新VFS實現的機制。在這個新的VFS接口中有一個稱為“xDeviceCharacteristics”的方法，它通過詢問文件系統來判斷文件系統是否支持某些特性。如果文件系統支持某個特性，SQLITE就會試著利用這個特性進行某種優化。默認的xDeviceCharacteristics不會指出文件系統支持原子的寫扇區操作，所以與此相關的優化都是關閉的。
SQLITE假設操作系統會緩沖寫操作，并且寫操作會在數據被真正寫到磁盤上之前返回。SQLITE還假設寫操作會被操作系統記錄下來。因此，SQLITE會在關鍵點上執行“flush”或“fsync”，并假設“flush”和“fsync”會等所有正在進行的“寫操作”真正執行完畢后才返回。在某些版本的windows和unix上，“flush”和“fsync”原語會被打斷，這非常不幸，在這些系統上，如果提交的過程中發生了掉電，SQLITE的數據庫有可能崩潰掉，而SQLITE自己則對此無能為力。SQLITE假設操作系統能像廣告宣傳的那樣完美，如果事實并非如此，你只好祈求老天保佑不要經常掉電了。
SQLITE假設文件增長時，新增加的部分最初包含的是垃圾數據，然后它們會被實際的數據覆蓋掉。換句話說，SQLITE假設文件大小的變化發生在文件內容變化之前。這是個悲觀的假設，為了保證在從“文件大小改變”開始到“文件內容寫完”為止的這段時間內，系統掉電不會導致數據庫崩潰，SQLITE要做一些額外的工作。VFS的xDeviceCharacteristics也可能會指出文件系統總是先寫數據后更新文件的大小，這種情況下，SQLITE可以跳過一些過于小心的數據庫保護操作，從而減少一次提交所需的磁盤I/O數量。但目前windows和unix上的VFS實現都沒有做這個假設。
SQLITE假設文件刪除是原子的，至少從用戶程序的角度來看要是這樣。也就是說，如果SQLITE要刪除一個文件，并且刪除的過程中掉電了，那么電力恢復后，文件要么不能從文件系統中找到，要么它的內容和刪除之前一模一樣。如果文件還能從文件系統中找到，但內容被修改或清空了，那么數據庫極有可能會崩潰。
SQLITE假設檢測由宇宙射線、熱噪聲、驅動程序bug等引起的位錯誤（bit error）是操作系統和硬件的責任。SQLITE沒有在數據庫文件中增加任何冗余信息來檢測或糾正這類問題。SQLITE假設它所讀的數據與它上次所寫的數據總是完全相同。
3.??? 單文件提交
我們先來從整體上看看SQLITE在一個單獨的數據庫文件上操作時，要保證事務提交的原子性需要哪些步驟。為防止掉電時文件被破壞，文件格式在設計時也有相應考慮，相關細節和多數據庫提交技術將在后續章節討論。
3.1.??? 初始狀態
下圖給出了數據庫連接剛剛打開時計算機的狀態。圖的最右側是存儲在磁盤上的數據，每個小格代表一個扇區，藍色表示扇區存儲的是原始數據；圖的中間部分是操作系統的緩存，在當前的例子中，緩存是“冷”的，所以它的每個格都沒有著色；最左側是使用SQLITE的進程（譯注：本文的作者可能更喜歡unix，所以在windows上，原文中的部分“進程”用“線程”替換一下會更好，我沒有做這種替換，故需要您在閱讀過程中結合上下文判斷“進程”的具體含義）的內存，數據庫連接剛剛創建，還沒有讀任何數據，所以用戶的內存空間中什么也沒有。
3.2.??? 獲取一個“讀鎖”
SQLITE寫數據庫之前，必須先讀，這樣它才能知道數據庫中已經有些什么了。即使是單純的追加數據，SQLITE也要先從sqlite_master表中讀出數據庫的表結構，從而知道如何去解析INSERT語句，以及新數據應該保存到文件的哪個位置。
讀操作的第一步是獲取一個數據庫文件的“共享鎖”。這個共享鎖允許兩個或多個數據庫連接同時讀數據庫文件，但不許其他數據庫連接寫這個文件。這個鎖非常重要，因為，如果在讀數據的過程中另一個連接寫了數據，我們就可能讀到一個新數據和舊數據的混合體，這會讓其他連接的寫操作失去原子性。
請注意，共享鎖是操作系統的磁盤緩存實現的，而不是磁盤本身。一般來說，文件鎖僅僅是操作系統內核中的一些標志（細節取決于具體操作系統的接口層）。所以，當系統崩潰或掉電后，這個鎖就自動消失了。并且，通常情況下，創建這個鎖的進程退出后，鎖也會自動消失。
3.3.??? 從數據庫中讀數據
獲得共享鎖后，我們開始從數據庫文件中讀出數據。在這個例子中，由于我們假設最初的緩存是“冷”的，所以要先把數據從磁盤讀到操作系統的緩存，再把它們從緩存復制到用戶空間。后續的讀操作，由于部分或全部數據可能已經在緩存中了，或許就只需要從緩存復制到用戶空間這一步了。
一般情況下，我們不會需要數據庫文件的所有頁（譯注：頁是SQLITE對數據進行緩沖的最小單位，但本文中有時它和扇區是一個意思，請注意結合上下文區分），所以我們讀的只是它的一個子集。本例中，我們的數據庫文件有8個頁，而我們需要的是其中的3個。一個真實的數據庫可能有數千個頁，但每次查詢要訪問的一般只是其中很小的一部分。
3.4.??? 獲取一個預定（Reserved）鎖
在對數據庫做任何修改之前，SQLITE需要獲得一個預定鎖。預定鎖和共享鎖很像，它們都允許其他進程讀數據庫文件。并且，預定鎖也可以和多個共享鎖共存。但是，一個數據庫文件某一時刻只能有一個預定鎖，也就是只允許一個進程有寫數據的意圖。
預定鎖的目的是告訴整個系統：有一個進程要在不久的將來修改數據庫文件了，但它目前還沒有任何實際行動。由于僅僅是個“意圖”，其他進程還可以繼續自己的讀操作，但是它們不能也有這個意圖了。
3.5.??? 創建回滾日志（Journal）文件
在任何實質性的修改之前，SQLITE還需要創建一個獨立的回滾日志文件，并把所有要被替換的數據庫頁的原始內容寫到這個文件中去。實際上，日志文件將保存將數據庫文件恢復到原始狀態所需的全部信息。
日志文件有一個不大的文件頭（圖中用綠色表示），它記錄了數據庫文件的原始大小。如果數據庫文件因為修改變大了，我們仍然可以憑它來獲得文件的原始大小。數據庫頁和它們的對應的頁號會被放在一起寫到日志文件中去。
創建新文件時，大多數操作系統（windows、linux、macOSX等）并不會立即向磁盤寫數據。新文件一開始只存在于操作系統的緩存中，直到操作系統有空閑的時候，它才會真的去在磁盤上創建這個文件。這種方式讓用戶覺得文件創建非?？?#xff0c;起碼比真的去做磁盤I/O快多了。在下圖中，為了表示這一情形，我們只在操作系統緩存中畫了這個日志文件。
3.6.??? 在用戶空間中修改數據庫
數據庫頁的原始內容保存到日志文件后，就可以在用戶空間中修改了。每個數據庫連接有一份私有的用戶空間拷貝，所以這些修改只會被當前的連接看到，其他連接看到的仍然是操作系統緩存中未被修改的內容。在這種情況下，雖然有一個進程正在對數據庫進行修改，其他進程仍然可以繼續讀數據庫的原始內容。
3.7.??? 把日志文件“刷”到磁盤
下一步是把回滾日志文件的內容刷到具有持久性的存儲器上。后面你會看到，這是讓數據庫能夠在掉電情況下存活的關鍵之一。它可能要花不少時間，因為往持久性存儲器上寫東西一般是很慢的。
這一步通常比僅僅把回滾日志刷到磁盤上復雜的多。在大多數平臺上，你要刷（flush或fsync）兩次才行。第一次是日志文件的基本內容。然后修改日志文件的頭部，以反應日志文件中實際的頁面數。接著刷第二次，把文件頭刷上去。至于為什么要修改文件頭并多刷一次，我們將在后續章節討論。
3.8.??? 獲取一個獨占鎖
為了對數據庫文件進行真正的修改，我們需要一個獨占鎖。獲取這個鎖需要兩步，首先是獲取一個待決（Pending）鎖，然后再把它提升為獨占鎖。
待決鎖允許其他已經有了共享鎖的進程繼續讀數據庫文件，但它不允許創建新的共享鎖。設計它的目的是為了避免一大堆讀進程把寫進程給餓到。系統中可能會有幾十甚至上百個進程想讀數據庫文件，每個這樣的進程都要經歷一個“獲得共享鎖、讀數據、釋放鎖”的過程。如果很多進程都想讀同一個數據庫文件，那么一個極有可能現象是：新進程總是在已有的進程釋放共享鎖之前獲得一個新的共享鎖。這樣一來，數據庫文件就上就總有共享鎖了，要寫數據的進程可能會一直沒有機會得到自己的獨占鎖。通過禁止創建新的共享鎖，待決鎖解決了這個問題，已有的共享鎖會逐漸被釋放，最終，當它們全部被釋放后，待決鎖就可以升級到獨占鎖了。
3.9.??? 更新數據庫文件
一旦獲得獨占鎖，就可以保證沒有其他進程在讀這個數據庫文件了，這時更新它就是安全的了。一般來說，這里的更新只會影響到操作系統磁盤緩存這一層，而不會影響磁盤上的物理文件。
3.10.??? 把變化刷到存儲器
為了把數據庫的變化寫到持久性存儲器，我們還要再刷一次。這也是保證數據庫在掉電情況下不崩潰的關鍵。當然，向磁盤或閃存寫數據實在是太慢了，這一步和3.7節中的刷日志文件加在一起會消耗掉SQLITE一次事務提交的絕大部分時間。
3.11.??? 刪除日志文件
把所有變化都安全的寫到存儲器上以后，回滾日志文件就可以刪除了。這是提交事務的那個時間點。如果掉電或系統崩潰發生在這之前，后面將要介紹的恢復過程會讓數據庫文件回到修改之前的狀態，就好像什么都沒發生過一樣。如果掉電或系統崩潰發生在日志文件被刪除之后，那么所有的修改都會生效。所以，SQLITE對數據庫的修改全部有效還是全部無效，實際上是取決于這個日志文件是否存在。
刪除文件不一定真的是原子操作，但從用戶程序的角度來看，它卻好像總是原子的。進程總可以詢問操作系統“這個文件存在嗎？”并等到是或否的回答。如果事務提交過程中發生了掉電，SQLITE就會問操作系統是否存在回滾日志文件，存在則事務是不完整的，需要回滾，不存在則說明事務確實成功提交了。
SQLITE事務的實現依賴于回滾日志文件是否存在和用戶程序眼中的原子的文件刪除。所以，事務也是一個原子操作。
3.12.??? 釋放鎖
最后一步是釋放獨占鎖，這樣其他進程就又能訪問數據庫文件了。
在下圖中，我們看到，用戶空間中的數據在鎖被釋放后就清除了。如果是較早版本的SQLITE，這是實際情況。但從最近幾版開始，SQLITE不這么做了，因為下個操作可能還會用到它們。比起從操作系統的緩存或磁盤中讀數據來，重用這些已經在本地內存中的數據的性能要高得多。再次使用它們之前，我們要先得到一個共享鎖，然后再檢查一下在我們沒有鎖的這段時間內是否有別的進程修改了數據庫文件。數據庫的第一頁有一個計數器，每次對數據庫進行修改時都會遞增它。檢查這個計數器，就能知道數據庫是否被別的進程修改過了。如果修改過，就必須清除用戶空間中的數據并把新數據讀進來。但更大的可能是沒有任何修改，這樣就可以重用原有的數據，從而大幅提高效率。
4.??? 回滾
原子提交看起來是瞬間完成的，但很明顯，前面介紹的過程需要一定的時間才能完成。如果在提交過程中電源被切斷，為了讓整個過程看起來是瞬時的，我們必須回滾那些不完整的修改，并把數據庫恢復到事務開始之前的狀態。
4.1.??? 如果出了問題…
假設掉電發生在3.10節所講的那一步，也就是把數據庫變化刷到磁盤中去的時侯。電力恢復后，情況可能會像下圖所示的那樣。我們要修改三頁數據，但只成功完成了一頁，有一頁只寫了一部分，另一頁則一點都沒寫。
電力恢復后日志文件是完整的，這是個關鍵。3.7節中的操作就是為了保證在對數據文件做任何改變之前回滾日志的所有內容已經安全的寫到持久性存儲器中去了。
4.2.??? “熱的”回滾日志
任何進程第一次訪問數據庫文件之前，必須獲得一個3.2節中描述的共享鎖。然后，如果發現還有一個日志文件，SQLITE就會檢查這個回滾日志是不是“熱的”。我們必須回放熱日志文件，從而把數據庫恢復到一致的狀態。只有在一個程序正在提交事務時發生掉電或崩潰的情況下，才會出現熱日志文件。
日志文件在符合以下所有條件時才是熱的：
● 日志文件是存在的
● 日志文件不是空文件
● 數據庫文件上沒有預定鎖
● 日志文件頭中沒有主日志文件的文件名，或者，如果有主日志文件名的話，主日志文件是存在的。
熱日志文件告訴我們：之前有進程試圖提交一個事務，但由于某種原因，這個提交沒有完成。也就是說：數據庫處于一種不一致的狀態，使用之前必須修復（回滾）。
4.3.??? 獲取數據庫上的獨占鎖
處理熱日志的第一步是獲得數據庫文件上的獨占鎖，這可以防止兩個或更多的進程同時回放一個熱日志。
4.4.??? 回滾不完整的修改
獲得了獨占鎖，進程就有權力修改數據庫文件了。它從日志中讀出頁面的原有內容，然后把它們分別寫回到其在數據庫文件中的原始位置上去。前面說過，日志文件的頭部記錄了數據庫文件在事務開始前的大小，如果修改讓數據庫文件變大了，SQLITE會使用這一信息把文件截斷到原始大小。這一步結束之后，數據庫文件就應該和事務開始前一樣大，并且包含和那時完全一樣的數據了。
4.5.??? 刪除熱日志文件
日志中的所有信息都回放到數據庫文件，并將數據庫文件刷到磁盤（回滾時可能會再次掉電）以后，就可以刪除熱日志文件了。
4.6.??? 繼續前進，就像那個中斷了的事務根本沒發生過一樣
回滾的最后一步是把獨占鎖降級為共享鎖。此后，數據庫的狀態看起來就像那個中斷了的事務根本沒有開始過一樣了。由于整個回滾過程是完全自動、透明的，使用SQLITE的那個程序根本就不會知道有一個事務中斷并回滾了。
5.??? 多文件提交
通過ATTACHDATABASE命令，SQLITE允許一個數據庫連接使用多個數據庫文件。當在一個事務中修改多個文件時，所有文件都會被原子的更新。換句話說，或者所有文件都會被更新，或者一個也不會被更新。在多個文件上實現原子提交比在單個文件上實現更復雜，本章將解釋SQLITE是如何做到這一點的。
5.1.??? 每個數據庫一個日志
當一個事務涉及了多個數據庫文件時，每個數據庫都有自己回滾日志，并且對它們的鎖也是各自獨立的。下圖展示了三個數據庫文件在一個事務中被修改的情況，它所描述的狀態相當于單文件事務在第3.6節中的狀態。每個數據庫文件有各自的預定鎖，它們將要被修改的那些頁的原始內容已經寫進回滾日志了，但還沒有刷到磁盤上。用戶內存中的數據已經被修改了，不過數據庫文件本身還沒有任何變化。
相比之前，下圖做了一些簡化。在這張圖上，藍色仍然代表原始數據，粉紅色仍然代表新數據。但上面沒有畫出回滾日志和數據庫的頁，并且也沒有明確區分操作系統緩存中的數據和磁盤上的數據。所有這些在這張圖上仍然適用，不過即使把它們畫出來我們也學不到什么新的東西，所以，為了縮小圖幅，我們把它們省略掉了。
5.2.??? 主日志文件
多文件提交中的下一步是創建一個“主日志文件”。這個文件的名字是最初的數據庫文件名（也就是用sqlite3_open()打開的那個數據庫，而不是之后附加上來的那些）加上后綴“-mjHHHHHHHH”。其中HHHHHHHH是一個32位16進制隨機數，每次生成新的主日志文件時，它都會不同。
（注意：上面一段中用來生成主日志文件名的方法是3.5.0版中使用的方法。這個方法并沒有規范化，也不是SQLITE對外接口的一部分，在未來版本中，我們可能會修改它。）
主日志中沒有與原始數據庫頁面內容相關的信息，它里面保存的是所有參與到這個事務中的回滾日志文件的完整路徑。
主日志生成完畢后，會被立即刷到磁盤上，中間沒有任何別的操作。在unix系統上，主日志所在的目錄，也會被同步一下，以確保掉電后它也會出現在這個目錄下。
5.3.??? 更新回滾日志文件頭
下一步是把主日志的路徑記錄到回滾日志的文件頭中去，回滾日志創建時在文件頭預留了相應的空間。
主日志路徑寫到回滾日志文件頭之前和之后，要分別把回滾日志的內容往磁盤上刷一次。這可能有些效率損失，但非常重要，而且，幸運的是，刷第二次時一般只有一頁（最開始的那頁）數據有變化，所以整個操作可能并沒有想象的那么慢。
這個操作大致相當于單文件提交時的第7步，也就是第3.7節中的內容。
5.4.??? 更新數據庫文件
把回滾日志刷到磁盤上后，就可以安全的更新數據庫文件了。我們需要獲得所有數據庫文件上的獨占鎖，然后寫數據，并把這些數據刷到磁盤上去。這一步相當于單文件提交時的第8、9和10步。
5.5.??? 刪除主日志文件
下一步是刪除主日志文件，這是多文件事務被實際提交的時間點。它相當于單文件提交時的第11步，也就是刪除日志文件的那一步。
如果掉電或系統崩潰發生在這之后，重啟時，即使存在回滾日志文件，事務也不會被回滾。這里的區別在于回滾日志的文件頭里面有主日志的路徑。SQLITE只認為文件頭中沒有主日志文件路徑的回滾日志（單文件提交的情況）或主日志文件仍然存在的回滾日志是“熱的”，并且只會回放熱的回滾日志。
5.6.??? 清理回滾日志文件
最后是刪除所有的回滾日志文件，釋放獨占鎖以便其他進程發現數據的變化。這一步對應的是單文件提交時的第12步。
由于事務已經提交了，所以刪除這些文件在時間上并不是非常緊迫。當前的實現是刪除一個日志文件，并釋放其對應的數據庫文件上的獨占鎖，然后再接著處理下一個。今后，我們可能把它改成先刪除所有日志文件，再釋放獨占鎖。這里，只要保證刪除日志文件在前，釋放其對應的鎖在后就行，文件被刪除的順序或鎖被釋放的順序并不重要。
6.??? 提交中的更多細節
第3章從總體上介紹了SQLITE原子提交的實現方法，但漏掉了幾個重要的細節，本章將對它們進行一些補充說明。
6.1.??? 總是日志中記錄整個扇區
在把數據庫頁面的原始內容寫進回滾日志時，即使頁面比扇區小，SQLITE也會把完整的扇區寫進去。從前，SQLITE中的扇區大小是硬編碼的512字節，而最小頁面也是512字節，所以不會有什么問題。但從3.3.14版開始，SQLITE也支持扇區大小超過512字節的存儲器了，所以，從這一版起，當某個扇區中的任何頁面被寫進日志時，這個扇區中的其它頁面也會被一同寫進去。
掉電可能在寫扇區時發生，總是記錄整個扇區可以在這種情況下保證數據庫不被破壞。例如，我們假設每個扇區有四個頁面，現在2號頁面被修改了，為了把變化寫入這個頁面，底層硬件，因為它只能寫完整的扇區，也會把1、3、4號頁面重新寫一遍，如果寫操作被打斷，這三個頁面的數據可能就不對了。為了避免這種情況，必須把扇區中的所有頁面寫到回滾日志中去。
6.2.??? 日志文件中的垃圾數據
向日志文件末尾追加數據時，SQLITE一般悲觀的假設文件系統會先用垃圾數據把文件撐大，再用正確的數據覆蓋這些垃圾。換句話說，SQLITE假設文件體積先變大，之后才是寫入實際內容。如果掉電發生在文件已經變大但數據還未寫入時，回滾日志中就會包含垃圾數據。電力恢復后，另一個SQLITE進程會發現這個日志文件，并試圖恢復它，這就有可能把垃圾數據拷貝到數據庫文件，進而對其造成破壞。
為對付這個問題，SQLITE建立了兩道防線。首先，SQLITE在回滾日志的文件頭中記錄了實際的頁面數。這個數字一開始是0，所以，在回放一個不完整的回滾日志時，SQLITE會發現文件中沒有包含任何頁面，也就不會對數據庫做任何修改。提交之前，回滾日志會被刷到磁盤上，以保證其中沒有任何垃圾。之后，文件頭中的頁面數才會被改成實際的數值。文件頭總是保存在一個單獨的扇區去，所以，如果在覆蓋它或把它刷到磁盤上時發生掉電，其它頁面是不會被破壞的。注意回滾日志要往磁盤上刷兩次：第一次是寫頁面的原始內容，第二次是寫文件頭中的頁面數。
上一段描述的是同步選項設置為“full”（PRAGMAsynchronous=FULL）時的情形，這也是默認的設置。不過，當同步選項低于“normal”時，SQLITE只會刷一次日志文件，也就是修改完頁面數后的那一次。由于（大于0的）頁面數可能先于其它數據到達磁盤，這樣做有一定的風險。SQLITE假設文件系統會記錄寫請求，所以即使先寫數據后寫頁面數，頁面數也可能會先被磁盤記錄下來。所以，作為第二道防線，SQLITE在日志文件中為每頁數據都記錄了一個32位的校驗碼。回滾日志文件時，SQLITE會檢查這個校驗碼，一旦發現錯誤，就會放棄回滾操作。要注意的是，校驗碼無法完全保證頁面數據的正確性，數據有錯誤但校驗碼正確的概率雖然極小，卻不是零.。不過，校驗碼機制至少讓類似的事情看起來不那么容易發生了。
在同步選項設置為“full”時，就沒有必要用校驗碼了，我們只在同步選項低于“normal”時才需要它。然而，鑒于校驗碼是無害的，故不管同步選項如何設置，它們總是出現在回滾日志中的。
6.3.??? 提交之前的緩存溢出
第三章描述的過程假設提交之前所有的數據庫變化都能保存在內存中。一般來說就是這樣的，但特殊情況也會出現。這時，數據庫變化會在事務提交之前用完用戶緩存，需要把緩存中的內容提前寫入數據庫才行。
操作之前，數據庫連接處于第3.6步時的狀態：原始頁面的內容已經保存到回滾日志了，修改后的頁面位于用戶內存中。為了回收緩存，SQLITE執行第3.7到3.9步，也就是把回滾日志刷到磁盤上，獲取獨占鎖，然后把變化寫入數據庫。但后續步驟在事務真正提交之前都有所不同。SQLITE會在日志文件的最后追加一個文件頭（使用一個單獨的扇區），獨占鎖繼續保留，而執行流程將跳到第3.6步。當事務提交或再次回收緩存時，將重復執行第3.7和3.9步（由于第一次回收緩存時獲得了獨占鎖且一直沒有釋放，3.8步將被跳過）。
把預定鎖提升為獨占鎖將降低并發度，額外的刷磁盤操作也非常慢，所以回收緩存會嚴重影響系統效率。因此，只要有可能，SQLITE就不會使用它。
7.??? 優化
對程序的性能分析顯示，在絕大多數系統和絕大多數情況下，SQLITE把絕大部分時間消耗在了磁盤I/O上。所以，減少磁盤I/O的數量是最有可能大幅提升效率的方法。本章將介紹SQLITE在保證原子提交的前提下，為減少磁盤I/O而使用的一些技術。
7.1.??? 在事務之間保持緩存數據
在3.12節中，我們說過當釋放共享鎖時會丟棄所有已經在用戶緩存中的數據庫信息。之所以這樣做，是因為沒有共享鎖的時候其他進程能夠隨意修改數據庫文件的內容，從而導致已經緩存的數據過時。所以，每當一個新事務開始時，SQLITE都必須重新讀一次以前讀過的東西。這個操作并不像大家想象的那么糟糕，因為要重新讀的數據極有可能仍在操作系統的緩存中，所謂的“重讀”一般僅僅是把數據從內核空間拷貝到用戶空間而已。不過，即使如此，也是需要一些時間的。
從3.3.14版開始，我們在SQLITE中增加了一個機制來避免不必要的重讀。這些版本中，釋放共享鎖后，用戶緩存的頁面繼續保留。等到SQLITE啟動下一個事務并獲得共享鎖后，它會檢查是否有其他進程修改了數據庫文件。如果自上次釋放鎖后有修改，用戶緩存會被清空并重讀。但一般不會有任何修改，所以用戶緩存仍然有效，這樣很多不必要的讀操作就被避免了。
為了判斷數據庫文件是否被修改，SQLITE在文件頭（第24到27字節）中使用了一個計數器，每個修改操作都會遞增它。釋放數據庫鎖之前，SQLITE會記下這個計數器的值，等到再次獲得鎖以后，它比較記錄的值和實際的值，相同則重用已有的緩存數據，不同則清空緩存并重讀。
7.2.??? 獨占訪問模式
自3.3.14版開始，SQLITE中增加了“獨占訪問模式”。在這種模式下，SQLITE會在事務提交后繼續保留獨占鎖。這樣一來，其他進程就不能訪問數據庫了。不過，由于大多數的部署方案都只有一個進程訪問數據庫，所以一般不會有什么問題。獨占訪問模式讓以下三個減少磁盤I/O的方法成為了可能：
1)??? 除了第一個事務，不必每次遞增數據庫文件頭中的計數器。這通常意味著在數據庫文件和回滾日志中各自少刷一次1號頁面。?
2)??? 因為沒有別的進程能訪問數據庫，所以沒必要每次啟動事務時檢查計數器和清空用戶緩存。
3)??? 事務結束后可以截斷（譯注：把文件長度設置為0字節）回滾日志文件，而不是刪除它。在很多操作系統上，截斷比刪除快的多。
第三項優化，也就是用截斷代替刪除，并不要求一直擁有獨占鎖。理論上說，總是實現它，而不是只在獨占訪問模式下實現它是可能的，也許我們會在未來版本中讓其成為現實。不過，到目前為止（3.5.0版），這項優化仍然只在獨占訪問模式下有效。
7.3.??? 不記錄空閑頁面
從數據庫中刪除數據時，那些不再使用的頁面會被加到“空閑頁表”里去。之后的插入操作將首先使用這些頁面，而不是擴大數據庫文件。一些空閑頁面中也有重要數據，比如說其他空閑頁面的位置等等。但大多數空閑頁面的內容沒有用，我們把這些頁面稱為“葉頁”。修改葉頁的內容對數據庫沒有任何影響。
由于葉頁的內容沒用，SQLITE不會把它們在提交過程的第3.5步中記錄到回滾日志里去。也就是說，修改葉頁，但不在回滾過程中恢復它們對數據庫無害。同樣的，一個新葉頁的內容既不會在第3.9步中寫入數據庫也不會在第3.3步中被讀出來。在數據庫文件有空閑空間時，這項優化大幅減少了磁盤I/O的數量。
7.4.??? 單頁更新和原子扇區寫
從3.5.0版開始，新的VFS接口包含了一個名叫xDeviceCharacteristics的方法，它可以報告底層存儲器是否支持一些特性。這些特性中，有一個是“原子扇區寫”。
我們前面說過，SQLITE假設寫扇區是線性的，而不是原子的。線性寫從扇區的一端開始，逐字節寫到另一端結束。如果在線性寫的中間發生掉電，則可能扇區的一端被修改了，另一端卻保持不變。但在原子寫的情況下，扇區或者被完全更新了，或者完全沒有變化。
我們相信大多數現在磁盤驅動器實現了原子扇區寫。掉電時，驅動器使用電容中的電能和（或）盤片旋轉的動能完成正在進行的操作。然而，在系統寫調用與磁盤電子元件之間存在太多的層次，所以我們在Unix和windows的默認VFS實現上做了一個保守的假設，認為寫扇區不是原子的。另一方面，能對其使用的文件系統有更多發言權的設備廠商，如果它們的硬件確實支持原子扇區寫，也許會選擇打開xDeviceCharacteristics中的這個選項。
當寫扇區是原子的、數據庫頁面和扇區一樣大，而且數據庫的變化只涉及到一個頁面時，SQLITE會跳過整個記日志和同步過程，直接把修改后的頁面寫到數據庫文件上。數據庫文件第一頁上的修改計數器也會獨立修改，因為即使在更新它之前掉電也是無害的。
譯注：個人認為，如果硬件不支持原子扇區寫，是無法在軟件層次上實現絕對意義上的原子提交的。
7.5.??? 支持安全追加的文件系統
3.5.0版加入的另一項優化措施是基于文件系統的“安全追加”功能的。SQLITE假設向文件（特別是回滾日志文件）追加數據時，文件大小的改變早于文件內容增加。所以，如果掉電發生在文件變大之后，數據寫完之前，文件中就會包含垃圾數據。也可以通過VFS中的xDeviceCharacteristics方法指出文件系統支持“安全追加”功能，這意味著內容的增加早于大小的改變，所以掉電或系統崩潰不可能向日志文件中引入垃圾。
文件系統支持安全追加時，SQLITE總是在日志文件頭的頁面數字段中填入-1，表示回滾時要處理的頁面數應該根據日志文件的大小自動計算。這個-1不會被修改，所以提交時，我們可以不用單獨刷一次日志文件的第一頁。而且，當回收緩存時，也沒有必要在日志文件末尾再寫一個新的文件頭了，我們只要繼續在已有的日志文件上追加新頁面即可。
8.??? 對原子提交的測試
我們作為SQLITE的開發者，對其在掉電和系統崩潰時的健壯性充滿自信，因為，我們的自動測試過程在模擬的掉電故障下，對它的恢復能力進行了非常多的檢測。我們把這種模擬的故障稱為“崩潰測試”。
崩潰測試使用了一個修改過的VFS，以便模擬掉電或崩潰時可能出現的各種文件系統錯誤。它可以模擬出沒有完整寫入的扇區、因為寫操作沒有完成而包含垃圾數據的頁面、順序錯誤的寫操作等，這些錯誤在測試場景的各個路徑點上都會出現。崩潰測試不停地執行事務，讓模擬的掉電或系統崩潰發生在各個不同的時刻，造成各種不同的數據損壞。在模擬的崩潰事件發生之后，測試程序重新打開數據庫，檢測事務是否完全完成或者（看起來）根本沒有啟動，也就是數據庫是否處于一個一致的狀態。
SQLITE的崩潰測試幫助我們發現了恢復機制中的很多小問題（現在都已經修復了）。其中的一部分非常隱晦，單單通過代碼檢查和分析可能是發現不了的。這些經驗讓SQLITE的開發者相信：那些沒有使用類似崩潰測試的數據庫系統，非常有可能包含在系統崩潰或掉電時導致數據庫損壞的BUG。
9.??? 可能發生的問題
雖然SQLITE的原子提交機制本身是健壯的，但它卻有可能被惡意的對手或不那么完善的操作系統實現給打垮。本章將介紹幾個可能在掉電或系統崩潰時導致數據庫損壞的情形。
9.1.??? 有問題的鎖
SQLITE使用文件系統的鎖來保證某一時刻只有一個進程和數據庫連接可以修改數據庫。文件系統的鎖機制是在VFS層實現的，并且在每種操作系統上都有所不同。SQLITE自身的正確性依賴于這個實現的正確性。如果它出了問題，導致兩個或更多進程能同時修改一個數據庫文件，肯定會嚴重損壞數據庫。
有人向我們報告說windows的網絡文件系統和（Unix的，譯注）NFS的鎖都有些問題。我們驗證不了這些報告，但是考慮到在網絡文件系統上實現一個正確的鎖的難度，我們也無法否定它們。由于網絡文件系統的效率也很低，所以我們建議你最好是避免在其上使用SQLITE。如果一定要這么做的話，請考慮使用一個附加的鎖機制來保證即使文件系統自身的鎖機制不起作用時，也不會出現多個進程同時寫一個數據庫文件的情況。
蘋果Mac OSX計算機上預裝的SQLITE進行了一個擴展，可以在蘋果支持的所有網絡文件系統上使用一個替代的加鎖策略。只要所有進程使用統一的方式訪問數據庫文件，這個擴展就工作的很好。但不幸的是，這些加鎖機制是相互獨立的，如果一個進程用AFP鎖，另一個用點文件（dot-file）鎖，那這兩個進程就可能發生沖突，因為AFP鎖并不能禁止點文件鎖，反之亦然。
9.2.??? 不完整的刷磁盤操作
在第3.7節和3.10節中你已經看到，SQLITE要把系統緩存刷到磁盤上。在unix系統上，這是用fsync()系統調用來完成的，windows上則是用FlushFileBuffers()?？墒?#xff0c;我們收到的報告顯示，很多系統上的這些接口沒有廣告宣傳的那么好。我們聽說，在一些windows版本上，通過修改注冊表，可以完全禁用FlushFileBuffers()；而linux的某些歷史版本中的fsync僅僅是個什么也不干的空操作。我們還知道，即使是在FlushFileBuffers()或fsync()可以正常工作的系統上，IDE磁盤控制器也經常會在數據仍處在自己的緩存中時，撒謊說數據已經到達磁盤表面了。
在蘋果的系統上，如果你把fullsync選項打開（PRAGMAfullsync=ON），它可以保證數據確實刷到磁盤上了。Fullsync本身就很慢，而fullsync的實現還需要重置磁盤控制器，這會讓其他根本不相關的磁盤I/O也變慢，所以我們不建議你這樣做。
9.3.??? 文件刪除只完成了一半
SQLITE假設從用戶程序的角度看文件刪除是原子操作。如果刪除文件時掉電，電力恢復后，SQLITE期望這個文件或者不存在，或者是一個完整的、和刪除前一模一樣的文件。如果操作系統做不到這一點，事務就有可能不是原子的。
9.4.??? 文件中的垃圾
SQLITE的數據庫文件是普通的文件，其它用戶程序也可以打開它并任意的往里面寫數據，一些流氓程序就可能這樣做。垃圾數據的來源也可能是操作系統或磁盤控制器的BUG，尤其是那些會在掉電時觸發的BUG。對此類問題，SQLITE無能為力。
9.5.??? 刪除或重命名熱日志文件
如果發生了掉電或崩潰，并且生成了熱日志文件，那么，在另一個SQLITE進程打開它和數據庫文件并完成回滾之前，這兩個文件的名字絕對不能改變。在第4.2步時，SQLITE會在打開的數據庫文件所在的目錄下，尋找熱日志文件，這個文件的名字是從數據庫文件名派生而來的。所以，只要這兩個文件中的任何一個被移走或改名，就會找不到熱日志，也就不會進行回滾。
我們認為SQLITE恢復過程的失敗模式一般是這樣的：發生了掉電；電力恢復后，一位好心的用戶或者系統管理員開始清點損失；他們發現有一個名為“important.data”的文件，他們可能很熟悉這個文件，所以沒有對其進行任何操作；但崩潰后，磁盤上還有一個名為“important.data-journal”的熱日志文件，用戶把它刪除了，因為他們認為這個文件是系統中的垃圾。防止此類事件的唯一方法可能就是加強用戶教育了。
如果有多個鏈接（硬鏈接或符號鏈接）指向一個數據庫文件，那么生成的日志文件會依據打開數據庫文件時使用鏈接名來命名。如果發生了崩潰，并且下次打開數據庫時使用了另一個鏈接，則也會因為找不到熱日志文件而不進行回滾。
某些時候，掉電會導致文件系統出錯，以致新更改的文件名無法記錄，這時，文件就會被移動到“/lost+found”目錄下。為防止此類錯誤，SQLITE會在同步日志文件的同時，打開并同步一下這個文件所在的目錄。但是，一些八竿子打不著的程序，在數據庫文件所在目錄下創建其他文件的操作，也可能會導致文件被移動到“/lost+found”里去，這是SQLITE控制不了的，所以SQLITE對它也沒什么辦法。如果你正在使用此類名字空間易被損壞的文件系統（我們相信大多數現代的日志文件系統沒有此問題），我們建議你把SQLITE的數據庫文件放在單獨的子目錄中。
10.??? 總結和展望
不論是過去還是現在，總有人能發現一些SQLITE原子提交機制的失敗模式，開發者也不得不為此做一些補丁。但這類事情發生的已經越來越少了，失敗模式也變得越來越隱晦。不過，如果藉此認為SQLITE的原子提交邏輯已經無懈可擊了，肯定是相當愚蠢的。開發者們能承諾的只是盡量快速的修復新發現的BUG。
同時，我們也在尋找新的方法來優化這個提交機制。在Linux、MacOSX和windows上，當前的VFS實現都做了悲觀的假設。也許在與一些熟悉這些系統工作原理的專家交流之后，我們能放寬一些限制，讓它跑得更快些。特別的，我們猜測大部分現代文件系統已經具有了“安全追加”和“原子扇區寫”這兩個特性，但在確認之前，我們仍會保守的做最壞假設。
轉載于:https://www.cnblogs.com/lanru/archive/2010/09/06/1819405.html
總結
以上是生活随笔為你收集整理的SQLITE中原子提交的实现的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Perl 变量(1)--纯变量
- 下一篇： linux cmake编译源码,linu