什么可能阻止 SQLite WAL 文件被清除？

Question

我在两台具有相同硬件和软件设置的不同机器上遇到了三个 WAL 文件增长到约 3 GB 的海量文件的案例。数据库文件本身约为 7 GB。在正常运行时，WAL 要么不存在，要么只有几千字节。

我知道只要有不断打开的连接，WAL 就会增长是正常的，但即使关闭应用程序也不会摆脱 WAL 文件或共享内存文件。即使重新启动机器，而无需启动我的应用程序，并尝试使用 DB Browser for SQLite 打开数据库也无济于事。启动需要很长时间（我不知道确切的时间，但肯定超过 5 分钟）然后 WAL 和共享内存文件仍然存在，即使在关闭浏览器之后也是如此。

奇怪的是，这确实有帮助。我压缩了这三个文件以在本地进行调查，但随后我预感删除了原始文件并再次将文件解压缩回来。启动应用程序需要几秒钟，额外的文件就这样消失了。同样的事情发生在我的笔记本电脑上，解压后的文件。我在我的机器上运行了完整性检查，数据库似乎没问题。

这里是应用程序的粗略描述，如果有任何意义的话。

• EF Core 2.1.14（它使用 SQLite 3.28.0）
• .Net Framework 4.7.1
• 除了一些罕见的与只读访问的短暂重叠外，只有一个线程访问数据库
• 整个连接 (DbContext) 大约每 2 秒关闭一次
• 共享内存用于PRAGMA mmap_size = 268435456 (256 MiB)
• 同步模式为NORMAL
• 操作系统是 Windows 7

任何想法可能导致这种...怪癖？

Answer 1

我暂时切换到日记模式，这有助于报告错误而不是静默失败。

我遇到的错误是SQLITE_IOERR_WRITE。经过更多挖掘，结果发现导致这一切的根 Windows 错误是 665 - 遇到了 NTFS 文件系统限制。一个answer here然后把我引到了真正的原因：数据库的极端文件碎片。

复制文件减少了碎片，这就是为什么我提到的奇怪修复，复制文件，暂时有效。实际的解决方法是使用 Sysinternals 的 Contig 安排碎片整理。