刪除日志文件聽(tīng)起來(lái)是個(gè)糟糕的主意。它允許sqite在崩潰后將數(shù)據(jù)庫(kù)回滾到一致?tīng)顟B(tài)。如果在數(shù)據(jù)庫(kù)處于不一致?tīng)顟B(tài)時(shí)刪除它，則會(huì)留下?lián)p壞的數(shù)據(jù)庫(kù)。引用方形遺址:
如果確實(shí)發(fā)生崩潰或停電，并且磁盤(pán)上保留了一個(gè)熱日志，則必須將原始數(shù)據(jù)庫(kù)文件和熱日志保留在磁盤(pán)上，并帶有它們的原始名稱，直到數(shù)據(jù)庫(kù)文件被另一個(gè)SQLite進(jìn)程打開(kāi)并回滾為止。[.]
我們懷疑SQLite恢復(fù)的常見(jiàn)故障模式是這樣發(fā)生的：發(fā)生電源故障?；謴?fù)電源后，善意的用戶或系統(tǒng)管理員開(kāi)始四處查看磁盤(pán)是否損壞。他們看到了他們的數(shù)據(jù)庫(kù)文件，名為“import ant.data”。他們可能對(duì)這個(gè)文件很熟悉。但在崩盤(pán)后，也有一個(gè)熱門(mén)雜志名為“重要數(shù)據(jù)日記”。然后，用戶刪除熱門(mén)日志，認(rèn)為他們正在幫助清理系統(tǒng)。除了用戶教育之外，我們不知道有什么辦法可以阻止這種情況。
回滾應(yīng)該在下一次打開(kāi)數(shù)據(jù)庫(kù)時(shí)自動(dòng)發(fā)生，但如果進(jìn)程無(wú)法鎖定數(shù)據(jù)庫(kù)，則會(huì)失敗。正如其他人所說(shuō)，造成這種情況的一個(gè)可能原因是，另一個(gè)進(jìn)程目前正在進(jìn)行之中。如果數(shù)據(jù)庫(kù)位于NFS卷上，則另一種可能是過(guò)期的NFS鎖。在這種情況下，解決方法是將數(shù)據(jù)庫(kù)文件替換為未鎖定在NFS服務(wù)器上的新副本(MV database.db源.db；cp initial.db database.db)。請(qǐng)注意，sqlitFAQ建議注意并發(fā)訪問(wèn)NFS卷上的數(shù)據(jù)庫(kù)，因?yàn)镹FS文件鎖定的實(shí)現(xiàn)存在缺陷。
我無(wú)法解釋為什么刪除日志文件會(huì)讓您鎖定以前無(wú)法鎖定的數(shù)據(jù)庫(kù)。那是可復(fù)制的嗎？
順便說(shuō)一句，日志文件的存在并不一定意味著發(fā)生了崩潰，也不一定意味著需要回滾更改。Sqlitt有幾種不同的日志模式，并且在持久化或截?cái)嗄Ｊ街校偸菍?日記文件放在適當(dāng)?shù)奈恢?，并更改?nèi)容以指示是否有部分事務(wù)要回滾。
