Что может помешать очистке файлов SQLite WAL?

У меня было три случая, когда файлы WAL вырастали до огромных размеров ~ 3 ГБ на двух разных машинах с одинаковыми аппаратными и программными настройками. Сам файл базы данных весит ~7 ГБ. В обычном режиме работы WAL либо не существует, либо занимает несколько килобайт.

Я знаю, что WAL нормально растет, если постоянно открыто соединение, но даже закрытие приложения не избавляет от файла WAL или файла общей памяти. Даже перезапуск машины без запуска моего приложения и попытка открыть базу данных с помощью браузера БД для SQLite не помогают. Запуск занимает целую вечность (я не знаю точно, сколько времени, но определенно более 5 минут), а затем файлы WAL и общей памяти остаются даже после закрытия браузера.

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

Вот примерное описание приложения, если оно что-то значит.

  • EF Core 2.1.14 (использует SQLite 3.28.0)
  • .NET Framework 4.7.1
  • за исключением некоторого редкого кратковременного совпадения с доступом только для чтения, только один поток обращается к базе данных
  • все соединение (DbContext) закрывается примерно каждые 2 секунды максимум
  • общая память используется с PRAGMA mmap_size = 268435456 (256 МБ)
  • синхронный режим NORMAL
  • ОС виндовс 7

Любые идеи, что может быть причиной этой... причуды?


person relatively_random    schedule 17.11.2020    source источник


Ответы (1)


Я временно переключился в режим журнала, который сообщал об ошибках, а не молчал.

У меня была ошибка SQLITE_IOERR_WRITE. После дополнительных копаний выяснилось, что корневая ошибка Windows, вызывающая все это, была 665, что связано с ограничением файловой системы NTFS. ответ здесь затем привел меня к фактическая причина: крайняя фрагментация файлов базы данных.

Копирование файла уменьшает фрагментацию, поэтому упомянутое мною странное исправление — копирование файла — временно сработало. Фактическое исправление заключалось в том, чтобы запланировать дефрагментацию с помощью Contig от Sysinternals.

person relatively_random    schedule 28.12.2020