База данных SQLite3 или диск заполнены / образ диска базы данных искажен

для восстановления поврежденной базы данных можно использовать утилиту командной строки sqlite3. После установки переменных среды введите в оболочке следующие команды:

cd $DATABASE_LOCATION
echo '.dump'|sqlite3 $DB_NAME|sqlite3 repaired_$DB_NAME
mv $DB_NAME corrupt_$DB_NAME
mv repaired_$DB_NAME $DB_NAME

этот код помог мне восстановить базу данных SQLite, которую я использую как постоянное хранилище для основных данных и которая вызвала следующую ошибку при сохранении:

не удалось сохранить: NSError 259 в домене NSCocoaErrorDomain { NSFilePath = файл mydata.db NSUnderlyingException = Фатальная ошибка. База данных в файл mydata.децибел испорчен. Код ошибки SQLite: 11, "образ диска базы данных искажен"}

Я использую следующий скрипт для восстановления деформированных файлов sqlite:

#!/bin/bash

cat <( sqlite3 "" .dump | grep "^ROLLBACK" -v ) <( echo "COMMIT;" ) | sqlite3 "fix_"

большую часть времени, когда база данных sqlite искажена, все еще можно сделать дамп. Этот дамп-это в основном много операторов SQL, которые перестраивают базу данных.

некоторые строки могут отсутствовать в дампе (возможно, потому, что они повреждены). Если это так, инструкции INSERT отсутствующих строк будут заменены некоторыми комментариями, и скрипт закончится инструкция ROLLBACK Transaction.

Итак, что мы делаем здесь, мы делаем дамп (искаженные строки исключены), и мы заменяем откат фиксацией, чтобы весь сценарий дампа был зафиксирован вместо отката.

этот метод спас мне жизнь пару 100 раз уже \o/

чтобы избежать получения "база данных или диск заполнен" в первую очередь, попробуйте это, если у вас много ОЗУ:

sqlite> pragma temp_store = 2;

это говорит SQLite поместить временные файлы в память. (Сообщение "база данных или диск заполнены" не означает, что база данных заполнена или что диск заполнен! Это означает, что каталог temp заполнен.) У меня есть 256G ОЗУ, но только 2G /tmp, поэтому это отлично работает для меня. Чем больше у вас ОЗУ, тем больше файлов БД вы можете работать.

Если вы не получил много ОЗУ, попробуйте это:

sqlite> pragma temp_store = 1;
sqlite> pragma temp_store_directory = '/directory/with/lots/of/space';

temp_store_directory устарел (что глупо, так как temp_store не устарел и требует temp_store_directory), поэтому будьте осторожны с использованием этого в коде.

Я видел, как это происходит, когда база данных повреждена, вы пытались клонировать ее в новую ?

Safley копировать s SQLite db

безопасное копирование базы данных SQLite

скопировать базу данных SQLite тривиально легко. Это менее тривиально. так, чтобы не испортить его. Вот как:

shell$ sqlite3 some.db
sqlite> begin immediate;
<press CTRL+Z>
shell$ cp some.db some.db.backup
shell$ exit
sqlite> rollback;

Это даст вам хорошую чистую резервную копию, которая обязательно будет в правильном государство, с момента написания база данных на полпути через копирование процесс невозможен.

при использовании Google App Engine у меня была эта проблема. По какой-то причине я сделал следующее С тех пор Google App Engine никогда не запускался.

$ echo '' > /tmp/appengine.apprtc.root/*.db

чтобы исправить это, мне нужно было сделать вручную:

$ sqlite3 datastore.db
sqlite> begin immediate;
<press CTRL+Z>
$ cp datastore.db logs.db

а затем запустите Google App Engine с флагом:

$ dev_appserver.py --clear_datastore --clear_search_index

после этого он, наконец, работал.

во время разработки приложений я обнаружил, что сообщения поступают от частых и массовых операций вставки и обновления. Не забудьте вставить и обновить несколько строк или данных за одну операцию.

var updateStatementString : String! = ""

for item in cardids {
    let newstring = "UPDATE "+TABLE_NAME+" SET pendingImages = '\(pendingImage)\' WHERE cardId = '\(item)\';"
    updateStatementString.append(newstring)
}

print(updateStatementString)

let results = dbManager.sharedInstance.update(updateStatementString: updateStatementString)

return Int64(results)