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

Моя firebase database составляет около 25 МБ, и я подтвердил, что имя пользователя, получающее доступ к нему, а также разрешения на доступ к файлам не изменились в течение нескольких месяцев. У меня возникла проблема, когда запросы терпят неудачу из-за того, что «firebase database или диск заполнен», а затем иногда «проблема с диском на диске диска повреждена».

Если я не читаю это неправильно, мой диск не находится где-то близко (это сервер Ubuntu, 9.10, если он имеет какое-либо значение)

Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 19610300 2389596 16224560 13% / udev 10240 128 10112 2% /dev none 254136 0 254136 0% /dev/shm none 254136 36 254100 1% /var/run none 254136 0 254136 0% /var/lock none 254136 0 254136 0% /lib/init/rw 

В качестве теста я только что сделал действие, которое добавило новую запись, и все в порядке. Я пытаюсь определить, есть ли определенный набор действий, которые терпят неудачу. Однако после вставки (и проверки того, что она есть) количество байт на диске для базы данных не изменилось (ни вверх, ни вниз).

Использование утилиты командной строки приводит к чему-то вроде следующего, что неэффективно выглядит 🙂

 SQLite version 3.6.12 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> pragma integrity_check; *** in database main *** On tree page 2 cell 0: 2nd reference to page 26416 On tree page 2 cell 1: 2nd reference to page 26417 On tree page 2 cell 2: 2nd reference to page 26434 On tree page 2 cell 3: 2nd reference to page 26449 On tree page 2 cell 4: 2nd reference to page 26464 On tree page 2 cell 5: 2nd reference to page 26358 On tree page 2 cell 6: 2nd reference to page 26494 On tree page 2 cell 7: Child page depth differs On tree page 2 cell 8: 2nd reference to page 26190 On tree page 2 cell 8: Child page depth differs ... etc., etc. ... 

Любые идеи о том, где я должен смотреть дальше? Есть ли проблема с максимальным количеством строк в таблице или чем-то еще? Я прочитал несколько значений SQLite3 max, и ничто в моей базе данных не является чем-то близким к ним, насколько я могу судить.

Затем я просмотрел мои ежедневные резервные копии, и я вижу, что резервная копия базы данных не изменилась в размере файла в течение 3-4 дней – это очень странно. Я восстановил резервную копию базы данных до того, как она не изменилась в размере файла, и все еще возникают странные проблемы.

Я думаю, что мне придется (1) восстановить старую резервную копию и (2) перезапустить мои миграции Rails для исправления.

    Несколько вещей, чтобы рассмотреть:

    • Файлы DBite SQLite3 растут примерно в несколько раз по размеру страницы БД и не сжимаются, если вы не используете VACUUM . Если вы удалите несколько строк, освобожденное пространство будет помечено внутри и повторно использовано в последующих вставках. Поэтому вставка часто не вызывает изменения размера файла базы данных резервного копирования.

    • Вы не должны использовать традиционные средства резервного копирования для SQLite (или любой другой базы данных, если на то пошло), поскольку они не учитывают информацию состояния БД, которая имеет решающее значение для обеспечения неповрежденной базы данных. Особенно, копирование файлов БД в середине транзакции вставки – это рецепт катастрофы …

    • SQLite3 имеет API специально для резервного копирования или копирования баз данных, которые используются.

    • И да, кажется, что ваши файлы DB повреждены . Это может быть ошибка аппаратной / файловой системы. Или, может быть, вы скопировали их, пока они были в использовании? Или, возможно, восстановлена ​​резервная копия, которая не была должным образом взята?

    Чтобы восстановить поврежденную базу данных, вы можете использовать утилиту командной строки 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.db повреждена. Код ошибки SQLite: 11, «образ диска базы данных неверен»}

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

     #!/bin/bash cat <( sqlite3 "$1" .dump | grep "^ROLLBACK" -v ) <( echo "COMMIT;" ) | sqlite3 "fix_$1" 

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

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

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

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

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

     sqlite> pragma temp_store = 2; 

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

    Если у вас нет большого количества баранов, попробуйте следующее:

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

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

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

    Safley копируется как SQLite db

    Безопасная копия базы данных SQLite

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

     shell$ sqlite3 some.db sqlite> begin immediate;  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;  $ cp datastore.db logs.db 

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

     $ dev_appserver.py --clear_datastore --clear_search_index 

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

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

     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) 
    Давайте будем гением компьютера.