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