丝瓜视频在线看,91青青青国产在观免费2019

軟件介紹人氣軟件精品推薦相關(guān)文章網(wǎng)友評論下載地址
小編為您推薦： sqlite數(shù)據(jù)庫數(shù)據(jù)庫修復(fù)工具

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

官方介紹

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

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

SQLiteDoctor下載

SQLiteDoctor軟件使用功能

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

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

SQLiteDoctor支持所有標(biāo)準(zhǔn)的SEE sqlite加密：AES128，AES192和AES256。

表格面板

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

詳細(xì)日志

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

要求

MacOS 10.10.5或更高版本

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

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

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

1.文件被流氓線程或進(jìn)程覆蓋

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

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

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

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

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

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

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

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

1.3。刪除熱門日記

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

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

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

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

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

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

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

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

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

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

2.文件鎖定問題

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

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

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

2.2。Posix咨詢鎖由一個(gè)單獨(dú)的線程取消close（）

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

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

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

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

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

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

2.3。兩個(gè)進(jìn)程使用不同的鎖定協(xié)議

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

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

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

如果兩個(gè)進(jìn)程具有到同一數(shù)據(jù)庫文件的打開連接，并且一個(gè)進(jìn)程關(guān)閉其連接，則取消鏈接該文件，然后在其位置創(chuàng)建一個(gè)具有相同名稱的新數(shù)據(jù)庫文件并重新打開新文件，然后這兩個(gè)進(jìn)程將與不同的進(jìn)程通信具有相同名稱的數(shù)據(jù)庫文件。（請注意，這僅適用于Posix和Posix類系統(tǒng)，它允許文件在讀取和寫入時(shí)仍然打開時(shí)取消鏈接.Windows不允許這樣做。）由于回滾日志和WAL文件基于數(shù)據(jù)庫文件的名稱，兩個(gè)不同的數(shù)據(jù)庫文件將共享相同的回滾日志或WAL文件。其中一個(gè)數(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ù)庫文件在仍在使用時(shí)取消鏈接，則unix OS接口將向錯(cuò)誤日志發(fā)送SQLITE_WARNING消息。

2.5。指向同一文件的多個(gè)鏈接

如果單個(gè)數(shù)據(jù)庫文件有多個(gè)鏈接（硬鏈接或軟鏈接），那么這只是說該文件有多個(gè)名稱的另一種方式。如果兩個(gè)或多個(gè)進(jìn)程使用不同的名稱打開數(shù)據(jù)庫，那么它們將使用不同的回滾日志和WAL文件。這意味著如果一個(gè)進(jìn)程崩潰，另一個(gè)進(jìn)程將無法恢復(fù)正在進(jìn)行的事務(wù)，因?yàn)樗鼘⒉檎疫m當(dāng)日志的錯(cuò)誤位置。

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

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

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

2.6。跨fork（）進(jìn)行打開的數(shù)據(jù)庫連接

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

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

3.未能同步

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

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

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

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

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

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

3.2。使用PRAGMA禁用同步

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

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

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

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

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

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

4.2。假容量USB棒

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

5.記憶腐敗

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

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

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

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

6.1。Linux線程

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

6.2。QNX上的mmap（）失敗

在QNX上存在mmap（）的一些微妙問題，使得對單個(gè)文件描述符進(jìn)行第二次mmap（）調(diào)用可以使得從第一個(gè)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工程師意識到了這個(gè)問題，正在研究解決方案; 你讀這篇文章時(shí)可能已經(jīng)解決了這個(gè)問題。

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

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

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

7. SQLite配置錯(cuò)誤

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

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

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

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

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

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

8. SQLite中的錯(cuò)誤

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

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

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

如果數(shù)據(jù)庫是由SQLite版本3.7.0或更高版本編寫的，然后由SQLite版本3.6.23或更早版本再次編寫，以使數(shù)據(jù)庫文件的大小減小，那么下一次SQLite版本3.7.0訪問數(shù)據(jù)庫文件，它可能會報(bào)告數(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)損壞

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

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

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

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

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

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

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

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

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

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

SQLite版本3.7.0引入了許多SQLite數(shù)據(jù)庫文件格式的新增強(qiáng)功能（例如但不限于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)上鎖定邏輯中的細(xì)微競爭條件。當(dāng)數(shù)據(jù)庫文件需要恢復(fù)時(shí)，因?yàn)閷懭胨南惹斑M(jìn)程在事務(wù)中間崩潰并且兩個(gè)或多個(gè)進(jìn)程嘗試同時(shí)打開該數(shù)據(jù)庫，那么競爭條件可能導(dǎo)致其中一個(gè)進(jìn)程獲得錯(cuò)誤指示已完成恢復(fù)，允許該進(jìn)程繼續(xù)使用數(shù)據(jù)庫文件而不先運(yùn)行恢復(fù)。如果該進(jìn)程寫入文件，則該文件可能會損壞。這種競爭條件顯然存在于SQLite for Windows的所有早期版本中，可追溯到2004年。但競爭非常緊張。實(shí)際上，您需要一臺快速的多核計(jì)算機(jī)，在該計(jì)算機(jī)中啟動(dòng)兩個(gè)進(jìn)程以在兩個(gè)單獨(dú)的核心上同時(shí)運(yùn)行恢復(fù)。此缺陷僅在Windows系統(tǒng)上，并不影響posix OS界面。

更多>> 軟件截圖

上一張下一張 (1 / 1)

查看詳細(xì)截圖

推薦應(yīng)用

微信聊天記錄恢復(fù)器 12.70 MB / 中文 / 1.0 官方免費(fèi)版
下載
Excel修復(fù)專家 650.00 KB / 中文 / 8.0 免費(fèi)版
下載
Recuva(文件恢復(fù)大師) 2.53 MB / 中文 / 10.0 v1.52.1086 完全漢化綠色免費(fèi)版
下載
Recover My Files(刪除文件恢復(fù)工具) 9.40 MB / 中文 / 10.0 v4.9.4.1324 漢化綠色特別版
下載
數(shù)據(jù)恢復(fù)精靈 11.70 MB / 中文 / 10.0 v3.9 綠色特別版
下載
finaldata oem v2.0 3.44 MB / 中文 / 0.0 簡體中文正式特別版
下載
easyrecovery pro 6.0 中文版 5.74 MB / 中文 / 0.0 v6.22.06 綠色精簡破解版
下載
Leawo iOS Data Recovery(iOS數(shù)據(jù)恢復(fù)軟件) 22.40 MB / 英文 / 10.0 v3.2.1.0 官方特別版
下載

其他版本下載

精品推薦 sqlite

更多 (33個(gè)) >> sqlite sqlite專題是小編精選給大家的數(shù)據(jù)庫管理工具，可能有朋友不知道sqlite的作用，它是款遵守ACID的關(guān)系型數(shù)據(jù)庫管理系統(tǒng)。在編程開發(fā)上能夠那起著很大的作用！它幾乎支持所有電腦操作系統(tǒng)，完美兼容，不用擔(dān)心系統(tǒng)的配置與穩(wěn)定性！占用內(nèi)存小，就能輕松運(yùn)行！此番，帶來的專題包含了sq