SQLiteDoctor軟件下載 最新更新|軟件分類|軟件專題|手機版|論壇轉(zhuǎn)貼|軟件發(fā)布

您當前所在位置：首頁 → 應(yīng)用軟件 → 數(shù)據(jù)恢復(fù) → SQLiteDoctor(sqlite數(shù)據(jù)庫修復(fù)工具) v1.4.1 官方免費版

SQLiteDoctor(sqlite數(shù)據(jù)庫修復(fù)工具)

v1.4.1 官方免費版

SQLiteDoctor(sqlite數(shù)據(jù)庫修復(fù)工具)
  • 軟件大�。�16.3M
  • 軟件語言：中文
  • 軟件類型：國產(chǎn)軟件 / 數(shù)據(jù)恢復(fù)
  • 軟件授權(quán)：免費軟件
  • 更新時間：2019-07-15 13:14
  • 軟件等級：4星
  • 應(yīng)用平臺：WinXP, Win7, Win10
  • 軟件官網(wǎng)：

ITMOP本地下載文件大�。�16.3M

點贊好評0%（0） 差評差評0%（0）

軟件介紹人氣軟件精品推薦相關(guān)文章網(wǎng)友評論下載地址

小編為您推薦：sqlite數(shù)據(jù)庫數(shù)據(jù)庫修復(fù)工具

sqliteDoctor是專為救生員用戶打造的一款救生員sqlite數(shù)據(jù)庫修復(fù)工具，可以幫助用戶快速高效的進行sqlite數(shù)據(jù)恢復(fù)，還能夠查詢數(shù)據(jù)內(nèi)所有的word表格數(shù)據(jù)值，非常的方便高效，是救生員用戶必備的救生sqlite數(shù)據(jù)恢復(fù)助手軟件，歡迎感興趣的用戶快來IT貓撲網(wǎng)下載體驗吧！

官方介紹

一個基于sqlite數(shù)據(jù)庫引擎構(gòu)建的功能齊全的高性能關(guān)系數(shù)據(jù)庫管理系統(tǒng)。自2013年以來，cubeSQL已經(jīng)部署了超過8400萬次。

SQLiteDoctor已被公認為sqlite數(shù)據(jù)庫取證分析DFRWS 2018 Europe的最佳工具之一。

SQLiteDoctor下載

SQLiteDoctor軟件使用功能

易于使用的向?qū)?/strong>

要開始，只需選擇要恢復(fù)的sqlite數(shù)據(jù)庫和輸出數(shù)據(jù)庫文件。如果損壞的數(shù)據(jù)庫已加密，您可以選擇設(shè)置加密密鑰。

SQLiteDoctor支持所有標準的SEE sqlite加密：AES128，AES192和AES256。

SQLiteDoctor下載

表格面板

掃描數(shù)據(jù)庫以查找所有表和所有rowid值。如果無法找到特定表的最大RowID值，則使用N / A值，您可以手動將該值設(shè)置為高于您知道在該數(shù)據(jù)庫中為該表使用的最大rowid值的數(shù)值（如果不是輸入的值超過使用的默認值100000）。

SQLiteDoctor下載

詳細日志

恢復(fù)開始后，會生成詳細的日志輸出，以便讓您了解當前執(zhí)行的步驟。如果出現(xiàn)不可恢復(fù)的錯誤，將顯示紅色消息（帶有總錯誤計數(shù)標簽）。

SQLiteDoctor下載

相關(guān)說明

SQLite數(shù)據(jù)庫對腐敗具有很強的抵抗力。如果應(yīng)用程序崩潰，操作系統(tǒng)崩潰，甚至在事務(wù)中發(fā)生電源故障，則部分寫入的事務(wù)應(yīng)在下次訪問數(shù)據(jù)庫文件時自動回滾。

雖然SQLite可以抵抗數(shù)據(jù)庫損壞，但它并不是免疫的，在某些情況下，需要一個像SQLiteDoctor這樣的特殊工具才能完全恢復(fù)損壞的sqlite數(shù)據(jù)庫。

要求

MacOS 10.10.5或更高版本

Windows 7SP1 / 8.1 / 10或更高版本

如何破壞sqlite數(shù)據(jù)庫

SQLite數(shù)據(jù)庫對腐敗具有很強的抵抗力。如果應(yīng)用程序崩潰，操作系統(tǒng)崩潰，甚至在事務(wù)中發(fā)生電源故障，則部分寫入的事務(wù)應(yīng)在下次訪問數(shù)據(jù)庫文件時自動回滾�；謴�(fù)過程是完全自動的，不需要用戶或應(yīng)用程序的任何操作。雖然SQLite可以抵御數(shù)據(jù)庫損壞，但它并不是免疫的。本文檔描述了SQLite數(shù)據(jù)庫可能損壞的各種方法。

1.文件被流氓線程或進程覆蓋

SQLite數(shù)據(jù)庫文件是普通的磁盤文件。這意味著任何進程都可以打開文件并用垃圾覆蓋它。SQLite庫沒有什么能夠防范這種情況。

1.1。關(guān)閉后繼續(xù)使用文件描述符

我們已經(jīng)看到多個文件描述符在文件上打開的情況，然后該文件描述符被關(guān)閉并在SQLite數(shù)據(jù)庫上重新打開。后來，其他一些線程繼續(xù)寫入舊文件描述符，沒有意識到原始文件已經(jīng)關(guān)閉。但是因為SQLite重新打開了文件描述符，所以打算進入原始文件的信息最終會覆蓋部分SQLite數(shù)據(jù)庫，從而導(dǎo)致數(shù)據(jù)庫損壞。

其中一個例子發(fā)生在大約2013-08-30，在Fossil DVCS的規(guī)范存儲庫中。在那種情況下，文件描述符2（標準錯誤）在sqlite3_open_v2（）之前被錯誤地關(guān)閉（我們懷疑 是 stunnel ），因此用于存儲庫數(shù)據(jù)庫文件的文件描述符是2.稍后，應(yīng)用程序錯誤導(dǎo)致斷言（ ）通過調(diào)用write（2，...）發(fā)出錯誤消息的語句。但由于文件描述符2現(xiàn)在已連接到數(shù)據(jù)庫文件，因此錯誤消息覆蓋了數(shù)據(jù)庫的一部分。為防止出現(xiàn)此類問題，SQLite 版本3.8.1（2013-10-17）及以后拒絕對數(shù)據(jù)庫文件使用低編號文件描述符。（請參閱SQLITE_MINIMUM_FILE_DESCRIPTOR 了解更多信息。）

Facebook工程師在2014-08-12的博客文章中報告了使用封閉文件描述符導(dǎo)致?lián)p壞的另一個例子 。

1.2。事務(wù)處于活動狀態(tài)時備份或還原

在后臺運行自動備份的系統(tǒng)可能會嘗試在事務(wù)處理過程中制作SQLite數(shù)據(jù)庫文件的備份副本。然后，備份副本可能包含一些舊內(nèi)容和一些新內(nèi)容，因此會損壞。

制作SQLite數(shù)據(jù)庫的可靠備份副本的最佳方法是使用作為SQLite庫一部分的備份API。如果不這樣做，只要任何進程沒有正在進行的事務(wù)，就可以安全地復(fù)制SQLite數(shù)據(jù)庫文件。如果先前的事務(wù)失敗，那么將任何回滾日志（* -journal文件）或預(yù)寫日志（* -wal文件）與數(shù)據(jù)庫文件本身一起復(fù)制是很重要的。

1.3。刪除熱門日記

SQLite通常將所有內(nèi)容存儲在單個磁盤文件中。但是，在執(zhí)行事務(wù)時，在崩潰或電源故障后恢復(fù)數(shù)據(jù)庫所需的信息存儲在輔助日志文件中。這種日志文件被描述為“熱門”。日志文件與原始數(shù)據(jù)庫文件具有相同的名稱，并添加了-journal或-wal后綴。

SQLite必須查看日志文件才能從崩潰或電源故障中恢復(fù)。如果在崩潰或電源故障后移動，刪除或重命名熱日志文件，則自動恢復(fù)將不起作用，并且數(shù)據(jù)庫可能會損壞。

此問題的另一個表現(xiàn)是 由于使用不一致的8 + 3文件名而導(dǎo)致的數(shù)據(jù)庫損壞。

1.4。錯誤配對數(shù)據(jù)庫文件和熱門期刊

前面的示例是更一般問題的特定情況：SQLite數(shù)據(jù)庫的狀態(tài)由數(shù)據(jù)庫文件和日志文件控制。在靜止狀態(tài)下，日志文件不存在，只有數(shù)據(jù)庫文件才對。但是，如果日志文件確實存在，則必須將其與數(shù)據(jù)庫保持在一起以避免損壞。以下行為都可能導(dǎo)致腐敗：

在兩個不同的數(shù)據(jù)庫之間交換日志文件。

使用不同的日志文件覆蓋日志文件。

將日志文件從一個數(shù)據(jù)庫移動到另一個數(shù)據(jù)庫

復(fù)制數(shù)據(jù)庫文件而不復(fù)制其日志。

用另一個數(shù)據(jù)覆蓋數(shù)據(jù)庫文件而不刪除與原始數(shù)據(jù)庫關(guān)聯(lián)的任何熱日志。

2.文件鎖定問題

SQLite在數(shù)據(jù)庫文件和預(yù)寫日志或WAL文件上使用文件鎖 來協(xié)調(diào)并發(fā)進程之間的訪問。如果沒有協(xié)調(diào)，兩個線程或進程可能會嘗試同時對數(shù)據(jù)庫文件進行不兼容的更改，從而導(dǎo)致數(shù)據(jù)庫損壞。

2.1。鎖實現(xiàn)損壞或丟失的文件系統(tǒng)

SQLite依賴于底層文件系統(tǒng)來進行鎖定，正如文檔所說的那樣。但是一些文件系統(tǒng)在其鎖定邏輯中包含錯誤，因此鎖定并不總是像宣傳的那樣。特別是網(wǎng)絡(luò)文件系統(tǒng)和NFS尤其如此。如果在鎖定原語包含錯誤的文件系統(tǒng)上使用SQLite，并且如果兩個或多個線程或進程同時嘗試訪問同一數(shù)據(jù)庫，則可能導(dǎo)致數(shù)據(jù)庫損壞。

2.2。Posix咨詢鎖由一個單獨的線程取消close（）

SQLite在unix平臺上使用的默認鎖定機制是POSIX咨詢鎖定。不幸的是，POSIX咨詢鎖定具有設(shè)計怪癖，使其容易被濫用和失敗。特別是，同一進程中具有持有POSIX顧問鎖的文件描述符的任何線程都可以使用不同的文件描述符覆蓋該鎖。一個特別有害的問題是close（）系統(tǒng)調(diào)用將取消所有線程和進程中所有文件描述符的同一文件上的所有POSIX顧問鎖。

因此，例如，假設(shè)一個多線程進程有兩個或多個線程，它們與同一個數(shù)據(jù)庫文件有不同的SQLite數(shù)據(jù)庫連接。然后出現(xiàn)第三個線程，并希望自己從同一個數(shù)據(jù)庫文件中讀取內(nèi)容，而不使用SQLite庫。第三個線程執(zhí)行open（），read（）然后close（）。人們會認為這將是無害的。但是關(guān)閉（）系統(tǒng)調(diào)用導(dǎo)致所有其他線程刪除數(shù)據(jù)庫中的鎖。那些其他線程無法知道他們的鎖剛剛被破壞（POSIX沒有提供任何機制來確定這一點），所以他們繼續(xù)運行，假設(shè)他們的鎖仍然有效。這可能導(dǎo)致兩個或多個線程或進程同時嘗試寫入數(shù)據(jù)庫，從而導(dǎo)致數(shù)據(jù)庫損壞。

請注意，兩個或多個線程使用SQLite庫訪問同一SQLite數(shù)據(jù)庫文件是完全安全的。SQLite的unix驅(qū)動程序知道POSIX咨詢鎖定怪癖并解決它們。只有當線程試圖繞過SQLite庫并直接讀取數(shù)據(jù)庫文件時，才會出現(xiàn)此問題。

2.2.1。SQLite的多個副本鏈接到同一個應(yīng)用程序

正如前一段所指出的，SQLite采取措施解決POSIX顧問鎖定的怪癖。部分解決方法涉及保持開放SQLite數(shù)據(jù)庫文件的全局列表（互斥保護）。但是，如果SQLite的多個副本鏈接到同一個應(yīng)用程序，那么這個全局列表將有多個實例。使用SQLite庫的一個副本打開的數(shù)據(jù)庫連接將不知道使用另一個副本打開的數(shù)據(jù)庫連接，并且將無法解決POSIX顧問鎖定問題。一個close（）方法的一個連接操作可能在不知不覺中清除不同的數(shù)據(jù)庫連接上的鎖，導(dǎo)致數(shù)據(jù)庫損壞。

上面的場景聽起來很牽強。但是，SQLite開發(fā)人員已經(jīng)知道至少有一個商業(yè)產(chǎn)品正好發(fā)布了這個錯誤。供應(yīng)商來到SQLite開發(fā)人員尋求幫助，以追蹤他們在Linux和Mac上看到的一些不常見的數(shù)據(jù)庫損壞問題。這個問題最終被追溯到這樣一個事實，即應(yīng)用程序是連接兩個單獨的SQLite副本。解決方案是將應(yīng)用程序構(gòu)建過程更改為僅鏈接一個SQLite副本而不是兩個副本。

2.3。兩個進程使用不同的鎖定協(xié)議

SQLite在unix平臺上使用的默認鎖定機制是POSIX建議鎖定，但還有其他選項。通過使用sqlite3_open_v2（）接口選擇備用sqlite3_vfs，應(yīng)用程序可以使用可能更適合某些文件系統(tǒng)的其他鎖定協(xié)議。例如，可以選擇在必須在不支持POSIX建議鎖定的NFS文件系統(tǒng)上運行的應(yīng)用程序中使用點文件鎖定。

與同一數(shù)據(jù)庫文件的所有連接使用相同的鎖定協(xié)議非常重要。如果一個應(yīng)用程序正在使用POSIX顧問鎖，而另一個應(yīng)用程序正在使用點文件鎖定，則這兩個應(yīng)用程序?qū)⒉粫吹奖舜说逆i定，并且無法協(xié)調(diào)數(shù)據(jù)庫訪問，從而可能導(dǎo)致數(shù)據(jù)庫損壞。

2.4。在使用時取消鏈接或重命名數(shù)據(jù)庫文件

如果兩個進程具有到同一數(shù)據(jù)庫文件的打開連接，并且一個進程關(guān)閉其連接，則取消鏈接該文件，然后在其位置創(chuàng)建一個具有相同名稱的新數(shù)據(jù)庫文件并重新打開新文件，然后這兩個進程將與不同的進程通信具有相同名稱的數(shù)據(jù)庫文件。（請注意，這僅適用于Posix和Posix類系統(tǒng)，它允許文件在讀取和寫入時仍然打開時取消鏈接.Windows不允許這樣做。）由于回滾日志和WAL文件基于數(shù)據(jù)庫文件的名稱，兩個不同的數(shù)據(jù)庫文件將共享相同的回滾日志或WAL文件。其中一個數(shù)據(jù)庫的回滾或恢復(fù)可能會使用其他數(shù)據(jù)庫中的內(nèi)容，從而導(dǎo)致?lián)p壞。

換句話說，取消鏈接或重命名打開的數(shù)據(jù)庫文件會導(dǎo)致行為未定義且可能不合需要。

從SQLite 版本3.7.17（2013-05-20）開始，如果數(shù)據(jù)庫文件在仍在使用時取消鏈接，則unix OS接口將向錯誤日志發(fā)送SQLITE_WARNING消息。

2.5。指向同一文件的多個鏈接

如果單個數(shù)據(jù)庫文件有多個鏈接（硬鏈接或軟鏈接），那么這只是說該文件有多個名稱的另一種方式。如果兩個或多個進程使用不同的名稱打開數(shù)據(jù)庫，那么它們將使用不同的回滾日志和WAL文件。這意味著如果一個進程崩潰，另一個進程將無法恢復(fù)正在進行的事務(wù)，因為它將查找適當日志的錯誤位置。

換句話說，打開和使用具有兩個或多個名稱的數(shù)據(jù)庫文件會導(dǎo)致行為未定義且可能不合需要。

從SQLite 版本3.7.17（2013-05-20）開始，如果數(shù)據(jù)庫文件有多個硬鏈接，則unix OS界面將向錯誤日志發(fā)送SQLITE_WARNING消息。

從SQLite 版本3.10.0（2016-01-06）開始，unix OS界面將嘗試解析符號鏈接并按其規(guī)范名稱打開數(shù)據(jù)庫文件。在3.10.0版之前，通過符號鏈接打開數(shù)據(jù)庫文件類似于打開具有多個硬鏈接的數(shù)據(jù)庫文件并導(dǎo)致未定義的行為。

2.6�？鏵ork（）進行打開的數(shù)據(jù)庫連接

不要打開SQLite數(shù)據(jù)庫連接，然后fork（），然后嘗試在子進程中使用該數(shù)據(jù)庫連接。將導(dǎo)致各種鎖定問題，您很容易就會遇到損壞的數(shù)據(jù)庫。SQLite不是為支持這種行為而設(shè)計的。必須在子進程中打開子進程中使用的任何數(shù)據(jù)庫連接，而不是從父進程繼承。

如果在父進程中打開了連接，甚至不要在子進程的數(shù)據(jù)庫連接上調(diào)用sqlite3_close（）。關(guān)閉底層文件描述符是安全的，但sqlite3_close（） 接口可能會調(diào)用清除活動，這些活動將從父項下刪除內(nèi)容，從而導(dǎo)致錯誤甚至數(shù)據(jù)庫損壞。

3.未能同步

為了保證數(shù)據(jù)庫文件始終保持一致，SQLite偶爾會要求操作系統(tǒng)將所有掛起的寫入刷新到持久存儲，然后等待該刷新完成。這是使用Windows 下的unix和FlushFileBuffers（）下的fsync（）系統(tǒng)調(diào)用 完成的。我們將此備用寫入的刷新稱為“同步”。

實際上，如果只關(guān)注原子和一致寫入并且愿意放棄持久寫入，則同步操作不需要等到內(nèi)容完全存儲在持久性介質(zhì)上。相反，同步操作可以被認為是I / O障礙。只要在同步之前發(fā)生的所有寫入在同步之后發(fā)生的任何寫入之前完成，就不會發(fā)生數(shù)據(jù)庫損壞。如果同步作為I / O屏障運行而不是真正的同步，則電源故障或系統(tǒng)崩潰可能導(dǎo)致一個或多個先前提交的事務(wù)回滾（違反“ACID”的“持久”屬性）但數(shù)據(jù)庫至少會繼續(xù)保持一致，這就是大多數(shù)人關(guān)心的問題。

3.1。不支持同步請求的磁盤驅(qū)動器

不幸的是，大多數(shù)消費級大容量存儲設(shè)備都在于同步。磁盤驅(qū)動器一旦到達軌道緩沖區(qū)并且在實際寫入氧化物之前就會報告內(nèi)容在安全介質(zhì)上是安全的。這使得磁盤驅(qū)動器似乎運行得更快（這對于制造商來說非常重要，因此他們可以在貿(mào)易雜志中顯示出良好的基準數(shù)據(jù)）。并且公平地說，只要在軌道緩沖器實際寫入氧化物之前沒有功率損耗或硬復(fù)位，謊言通常不會造成傷害。但是，如果確實發(fā)生了斷電或硬復(fù)位，并且如果這導(dǎo)致在同步到達氧化物之后寫入的內(nèi)容而在同步之前寫入的內(nèi)容仍在軌道緩沖區(qū)中，則可能發(fā)生數(shù)據(jù)庫損壞。

USB閃存棒似乎是關(guān)于同步請求的特別惡毒的騙子。通過將大型事務(wù)提交到USB記憶棒上的SQLite數(shù)據(jù)庫，可以很容易地看到這一點。COMMIT命令將相對快速地返回，表明記憶棒告訴操作系統(tǒng)并且操作系統(tǒng)告訴SQLite所有內(nèi)容都安全地存在于持久存儲中，但記憶棒末端的LED將繼續(xù)閃爍幾個更多秒。在LED仍在閃爍時拔出記憶棒會經(jīng)常導(dǎo)致數(shù)據(jù)庫損壞。

請注意，SQLite必須相信操作系統(tǒng)和硬件告訴它有關(guān)同步請求狀態(tài)的任何信息。SQLite無法檢測到任何一個正在撒謊并且寫入可能無序發(fā)生。但是，WAL模式下的 SQLite對于無序?qū)懭氡葘δJ回滾日志模式要寬松得多。在WAL模式下，失敗的同步操作可能導(dǎo)致數(shù)據(jù)庫損壞的唯一時間是在檢查點操作期間。COMMIT期間的同步失敗可能導(dǎo)致耐久性丟失，但不會導(dǎo)致?lián)p壞的數(shù)據(jù)庫文件。因此，由于同步操作失敗導(dǎo)致數(shù)據(jù)庫損壞的一條防線是在WAL模式下使用SQLite并盡可能不頻繁地檢查點。

3.2。使用PRAGMA禁用同步

可以使用同步編譯指示在運行時禁用SQLite執(zhí)行以幫助確保完整性的同步操作。通過設(shè)置PRAGMA synchronous = OFF，省略所有同步操作。這使得SQLite似乎運行得更快，但它也允許操作系統(tǒng)自由地重新排序?qū)懭耄绻谒袃?nèi)容到達持久存儲之前發(fā)生電源故障或硬重置，則可能導(dǎo)致數(shù)據(jù)庫損壞。

為了獲得最大的可靠性和針對數(shù)據(jù)庫損壞的穩(wěn)健性，SQLite應(yīng)始終以其默認同步設(shè)置FULL運行。

4.磁盤驅(qū)動器和閃存故障

如果文件內(nèi)容因磁盤驅(qū)動器或閃存故障而發(fā)生更改，則SQLite數(shù)據(jù)庫可能會損壞。這是非常罕見的，但磁盤偶爾會在扇區(qū)中間翻轉(zhuǎn)一下。

4.1。非電源安全閃存控制器

我們被告知，在一些閃存控制器中，如果在寫入期間電源中斷，則耗損均衡邏輯可能導(dǎo)致隨機文件系統(tǒng)損壞。例如，這可以表現(xiàn)為在斷電時甚至沒有打開的文件中間的隨機變化。因此，例如，當發(fā)生斷電時，設(shè)備會將內(nèi)容寫入閃存中的MP3文件，這可能導(dǎo)致SQLite數(shù)據(jù)庫損壞，即使數(shù)據(jù)庫在斷電時甚至沒有使用。

4.2。假容量USB棒

有許多流通的USB棒在報告中具有高容量（例如：8GB），但實際上只能存儲少量（例如：1GB）。嘗試在這些設(shè)備上寫入通常會導(dǎo)致不相關(guān)的文件被覆蓋。因此，任何使用欺詐性閃存設(shè)備都很容易導(dǎo)致數(shù)據(jù)庫損壞。諸如“假容量usb”之類的互聯(lián)網(wǎng)搜索將會發(fā)現(xiàn)許多有關(guān)此問題的令人不安的信息。

5.記憶腐敗

SQLite是一個C庫，它在與它所服務(wù)的應(yīng)用程序相同的地址空間中運行。這意味著應(yīng)用程序中的雜散指針，緩沖區(qū)溢出，堆損壞或其他故障可能會破壞內(nèi)部SQLite數(shù)據(jù)結(jié)構(gòu)，并最終導(dǎo)致?lián)p壞的數(shù)據(jù)庫文件。通常情況下，這些類型的問題在任何數(shù)據(jù)庫損壞發(fā)生之前都表現(xiàn)為段錯誤，但是有些情況下應(yīng)用程序代碼錯誤導(dǎo)致SQLite發(fā)生故障，從而破壞數(shù)據(jù)庫文件而不是恐慌。

使用內(nèi)存映射I / O時，內(nèi)存損壞問題變得更加嚴重。當全部或部分數(shù)據(jù)庫文件映射到應(yīng)用程序的地址空間時，覆蓋該映射空間的任何部分的雜散指針將立即破壞數(shù)據(jù)庫文件，而不需要應(yīng)用程序執(zhí)行后續(xù)的write（）系統(tǒng)調(diào)用。

6.其他操作系統(tǒng)問題

有時，操作系統(tǒng)會出現(xiàn)可能導(dǎo)致問題的非標準行為。有時這種非標準行為是故意的，有時在實施中是錯誤的。但無論如何，如果操作的執(zhí)行方式與SQLite期望執(zhí)行的方式不同，則存在數(shù)據(jù)庫損壞的可能性。

6.1。Linux線程

一些舊版本的Linux使用LinuxThreads庫來提供線程支持。LinuxThreads類似于Pthreads，但在處理POSIX顧問鎖方面略有不同。SQLite版本2.2.3到3.6.23認識到LinuxThreads正在運行時使用，并采取適當?shù)拇胧﹣斫鉀QLinuxThreads的非標準行為。但是大多數(shù)現(xiàn)代Linux實現(xiàn)都使用了Pthreads的更新，更正確的NPTL實現(xiàn)。從SQLite 版本3.7.0（2010-07-21）開始，假設(shè)使用NPTL。沒有檢查。因此，如果在使用LinuxThreads的舊linux系統(tǒng)上運行的多線程應(yīng)用程序中使用，SQLite的最新版本將巧妙地出現(xiàn)故障并可能損壞數(shù)據(jù)庫文件。

6.2。QNX上的mmap（）失敗

在QNX上存在mmap（）的一些微妙問題，使得對單個文件描述符進行第二次mmap（）調(diào)用可以使得從第一個mmap（）調(diào)用獲得的內(nèi)存歸零。unix上的SQLite使用mmap（）為WAL模式下的事務(wù)協(xié)調(diào)創(chuàng)建共享內(nèi)存區(qū)域，并且它將為大事務(wù)多次調(diào)用mmap（）。已證明QNX mmap（）在該場景下?lián)p壞了數(shù)據(jù)庫文件。QNX工程師意識到了這個問題，正在研究解決方案; 你讀這篇文章時可能已經(jīng)解決了這個問題。

當QNX運行，建議內(nèi)存映射I / O永遠不會被使用。此外，要使用WAL模式，建議應(yīng)用程序采用獨占鎖定模式，以便在沒有共享內(nèi)存的情況下使用WAL。

6.3。文件系統(tǒng)腐敗

由于SQLite數(shù)據(jù)庫是普通的磁盤文件，因此文件系統(tǒng)中的任何故障都可能破壞數(shù)據(jù)庫�，F(xiàn)代操作系統(tǒng)中的文件系統(tǒng)非�？煽�，但仍然會發(fā)生錯誤。例如，在2013-10-01，持有Wiki for Tcl / Tk的SQLite數(shù)據(jù)庫 在主機被轉(zhuǎn)移到文件系統(tǒng)層中存在問題的（linux）內(nèi)核的狡猾版本后幾天就被破壞了。在那種情況下，文件系統(tǒng)最終變得如此嚴重損壞，以至于機器無法使用，但最早出現(xiàn)問題的癥狀是SQLite數(shù)據(jù)庫損壞。

7. SQLite配置錯誤

SQLite有許多針對數(shù)據(jù)庫損壞的內(nèi)置保護。但是配置選項可以禁用許多這些保護。如果禁用保護，則可能會發(fā)生數(shù)據(jù)庫損壞。

以下是禁用SQLite內(nèi)置保護機制的示例：

如果出現(xiàn)操作系統(tǒng)崩潰或電源故障，設(shè)置PRAGMA synchronous = OFF會導(dǎo)致數(shù)據(jù)庫損壞，但此設(shè)置可以避免因應(yīng)用程序崩潰而造成的損壞。

在打開其他數(shù)據(jù)庫連接時更改PRAGMA schema_version。

使用PRAGMA journal_mode = OFF或PRAGMA journal_mode = MEMORY 并在寫入事務(wù)中使應(yīng)用程序崩潰。

設(shè)置PRAGMA writable_schema = ON然后使用DML語句更改數(shù)據(jù)庫模式可能會使數(shù)據(jù)庫完全不可讀，如果不仔細完成的話。

8. SQLite中的錯誤

SQLite經(jīng)過了非常仔細的測試，以幫助確保它盡可能沒有錯誤。在為每個SQLite版本執(zhí)行的許多測試中，有一些模擬電源故障，I / O錯誤和內(nèi)存不足（OOM）錯誤的測試，并驗證在任何這些事件期間都沒有發(fā)生數(shù)據(jù)庫損壞。SQLite也經(jīng)過現(xiàn)場驗證，大約有20億次活動部署，沒有嚴重問題。

然而，沒有軟件100％完美。SQLite（現(xiàn)已修復(fù)）中存在一些可能導(dǎo)致數(shù)據(jù)庫損壞的歷史錯誤。還有一些還未被發(fā)現(xiàn)。由于SQLite的廣泛測試和廣泛使用，導(dǎo)致數(shù)據(jù)庫損壞的錯誤往往非常模糊。應(yīng)用程序遇到SQLite錯誤的可能性很小。為了說明這一點，下面給出了一個帳戶，其中列出了在2009-04-01至2013-04-15四年期間SQLite中發(fā)現(xiàn)的所有數(shù)據(jù)庫損壞錯誤。這個帳戶應(yīng)該讓讀者直觀地了解SQLite中存在的各種錯誤，這些錯誤可以通過測試程序完成，并使其成為一個版本。

8.1。由于數(shù)據(jù)庫收縮導(dǎo)致的虛假損壞報告

如果數(shù)據(jù)庫是由SQLite版本3.7.0或更高版本編寫的，然后由SQLite版本3.6.23或更早版本再次編寫，以使數(shù)據(jù)庫文件的大小減小，那么下一次SQLite版本3.7.0訪問數(shù)據(jù)庫文件，它可能會報告數(shù)據(jù)庫文件已損壞。但是，數(shù)據(jù)庫文件并沒有真正損壞。版本3.7.0在腐敗檢測中過于熱心。

問題已在2011-02-20修復(fù)。該修復(fù)程序首先出現(xiàn)在SQLite 版本3.7.6（2011-04-12）中。

8.2。在回滾和WAL模式之間切換后出現(xiàn)損壞

在一個進程或線程中反復(fù)切換進出WAL模式的SQLite數(shù)據(jù)庫并在交換機之間 運行VACUUM命令會導(dǎo)致另一個打開數(shù)據(jù)庫文件的進程或線程錯過數(shù)據(jù)庫已更改的事實。然后，第二個進程或線程可能會嘗試使用陳舊緩存修改數(shù)據(jù)庫并導(dǎo)致數(shù)據(jù)庫損壞。

這個問題是在內(nèi)部測試中發(fā)現(xiàn)的，從未在野外觀察到過。問題已在2011-01-27和3.7.5版本中修復(fù)。

8.3。獲取鎖定時的I / O錯誤會導(dǎo)致?lián)p壞

如果操作系統(tǒng)在嘗試在WAL模式下獲得對共享內(nèi)存的某個鎖定時返回I / O錯誤，則SQLite可能無法重置其緩存，如果嘗試后續(xù)寫入，則可能導(dǎo)致數(shù)據(jù)庫損壞。

請注意，只有在嘗試獲取鎖定導(dǎo)致I / O錯誤時才會出現(xiàn)此問題。如果沒有授予鎖定（因為某些其他線程或進程已經(jīng)存在沖突鎖定），則不會發(fā)生任何損壞。我們不知道在嘗試獲取共享內(nèi)存上的文件鎖時，任何操作系統(tǒng)都會因I / O錯誤而失敗。所以這是一個理論問題，而不是一個真正的問題。不用說，在野外從未觀察到這個問題。在模擬I / O錯誤的測試工具中對SQLite進行壓力測試時發(fā)現(xiàn)了這個問題。

對于SQLite版本3.7.3，此問題已于2010-09-20修復(fù)。

8.4。數(shù)據(jù)庫頁面從空閑頁面列表中泄漏

從SQLite數(shù)據(jù)庫中刪除內(nèi)容時，不再使用的頁面將添加到空閑列表中，并重新用于保存后續(xù)插入添加的內(nèi)容。在使用incremental_vacuum時，版本3.6.16到3.7.2中存在的SQLite中的錯誤可能會導(dǎo)致頁面丟失在空閑列表之外。這不會導(dǎo)致數(shù)據(jù)丟失。但是這會導(dǎo)致數(shù)據(jù)庫文件超出必要的范圍。并且它會導(dǎo)致integrity_check編譯指示報告空閑列表中缺少的頁面。

對于SQLite版本3.7.2，此問題已在2010-08-23修復(fù)。

8.5。從3.6和3.7交替寫入后的腐敗。

SQLite版本3.7.0引入了許多SQLite數(shù)據(jù)庫文件格式的新增強功能（例如但不限于WAL）。3.7.0版本是這些新功能的震撼發(fā)布。我們期待找到問題并且沒有失望。

如果最初使用SQLite版本3.7.0創(chuàng)建數(shù)據(jù)庫，然后由SQLite版本3.6.23.1編寫，使得數(shù)據(jù)庫文件的大小增加，然后由SQLite版本3.7.0再次編寫，則數(shù)據(jù)庫文件可能會損壞。

對于SQLite版本3.7.1，此問題已在2010-08-04修復(fù)。

8.6。Windows系統(tǒng)恢復(fù)中的競爭條件。

SQLite版本3.7.16.2修復(fù)了Windows系統(tǒng)上鎖定邏輯中的細微競爭條件。當數(shù)據(jù)庫文件需要恢復(fù)時，因為寫入它的先前進程在事務(wù)中間崩潰并且兩個或多個進程嘗試同時打開該數(shù)據(jù)庫，那么競爭條件可能導(dǎo)致其中一個進程獲得錯誤指示已完成恢復(fù)，允許該進程繼續(xù)使用數(shù)據(jù)庫文件而不先運行恢復(fù)。如果該進程寫入文件，則該文件可能會損壞。這種競爭條件顯然存在于SQLite for Windows的所有早期版本中，可追溯到2004年。但競爭非常緊張。實際上，您需要一臺快速的多核計算機，在該計算機中啟動兩個進程以在兩個單獨的核心上同時運行恢復(fù)。此缺陷僅在Windows系統(tǒng)上，并不影響posix OS界面。

更多>>軟件截圖

推薦軟件

其他版本下載

    精品推薦sqlite

    sqlite
    更多 (33個) >>sqlitesqlite專題是小編精選給大家的數(shù)據(jù)庫管理工具，可能有朋友不知道sqlite的作用，它是款遵守ACID的關(guān)系型數(shù)據(jù)庫管理系統(tǒng)。在編程開發(fā)上能夠那起著很大的作用！它幾乎支持所有電腦操作系統(tǒng)，完美兼容，不用擔心系統(tǒng)的配

    相關(guān)文章

    下載地址

    • SQLiteDoctor(sqlite數(shù)據(jù)庫修復(fù)工具) v1.4.1 官方免費版

    查看所有評論>>網(wǎng)友評論

    發(fā)表評論

    (您的評論需要經(jīng)過審核才能顯示) 網(wǎng)友粉絲QQ群號:203046401

    查看所有0條評論>>

    更多>>猜你喜歡