问题描述
我在iOS应用程式中的Core Data有一个奇怪的问题，有时WAL档案变成巨大的（〜1GB）。看来有其他人有问题（例如。）
I have a strange problem with Core Data in an iOS app where sometimes the WAL file becomes huge (~1GB). It appears there are other people with the problem (e.g. Core Data sqlite-wal file gets MASSIVE (>7GB) when inserting ~5000 rows).
我最初的想法是删除WAL文件。看来似乎从阅读sqlite文档上的事情，这将是好的。但是，有没有人知道这样做有任何缺点？
My initial thought is to delete the WAL file at app launch. It seems from reading the sqlite documentation on the matter that this will be fine. But does anyone know of any downsides to doing this?
我当然想了解为什么WAL文件增长如此之大，但我可以现在已经到底，希望在解决问题时能解决问题。
I'd of course like to get to the bottom of why the WAL file is growing so big, but I can't get to the bottom of it right now and want to put in a workaround while I dig deeper into the problem.
值得指出的是，我的Core Data数据库更多的缓存。所以，如果我丢失在WAL中的数据没关系。我真正需要知道的是，如果我删除WAL数据库将完全损坏？
It's worth pointing out that my Core Data database is more of a cache. So it doesn't matter if I lose data that's in the WAL. What I really need to know is, will the database be completely corrupted if I delete the WAL? My suspicion is no, otherwise the WAL doesn't serve one of its purposes.
推荐答案
WAL模式有问题，不要用它。问题各不相同，但报告的大小非常大，其他问题包括迁移期间的失败（使用NSPersistentStoreCoordinators migratePersistentStore）和导入iCloud事务日志期间的失败。所以虽然有报告的好处，直到这些错误是固定的，它可能是不明智的使用WAL模式。
WAL mode has problems, don't use it. Problems vary but the very large size your report is one, other problems include failure during migration (using NSPersistentStoreCoordinators migratePersistentStore) and failure during importing of iCloud transaction logs. So while there are reported benefits until these bugs are fixed its probably unwise to use WAL mode.
无法删除预先写入的日志，因为它包含最新的数据。
And NO you can't delete the Write Ahead Log, because that contains the most recent data.
设置数据库使用回滚日志模式，我想你会发现你不再有这些非常大的文件，当加载大量的数据。
Set the database to use rollback journal mode and I think you will find you no longer have these very large files when loading lots of data.
以下是解释WAL如何工作的摘录。除非你能保证你的应用程序运行了一个检查点，我不会看到如何删除WAL文件，而不会有删除已提交的事务的风险。
Here is an extract which explains how WAL works. Unless you can guarantee that your app has run a checkpoint I don't see how you can delete the WAL file without running the risk of deleting committed transactions.
传统的回滚日志的工作原理是将
原始未更改的数据库内容复制到单独回滚日志
文件，然后将更改直接写入数据库文件。在崩溃或ROLLBACK的
事件中，包含在
回滚日志中的原始内容被回放到数据库文件中以将
数据库文件恢复到其原始状态。删除
回滚日志时会发生COMMIT。
The traditional rollback journal works by writing a copy of the original unchanged database content into a separate rollback journal file and then writing changes directly into the database file. In the event of a crash or ROLLBACK, the original content contained in the rollback journal is played back into the database file to revert the database file to its original state. The COMMIT occurs when the rollback journal is deleted.
WAL方法会将此反转。原始内容保存在
数据库文件中，更改附加到单独的WAL
文件中。当指示提交的特殊记录是附加到WAL的
时，发生COMMIT。因此，COMMIT可以发生，没有写
原始数据库，这允许读者继续操作从
原始未更改的数据库，同时更改同时
提交到WAL。多个交易可以附加到单个WAL文件的
结尾。
The WAL approach inverts this. The original content is preserved in the database file and the changes are appended into a separate WAL file. A COMMIT occurs when a special record indicating a commit is appended to the WAL. Thus a COMMIT can happen without ever writing to the original database, which allows readers to continue operating from the original unaltered database while changes are simultaneously being committed into the WAL. Multiple transactions can be appended to the end of a single WAL file.
检查点
当然，一个人想要最终将
在WAL文件中附加的所有事务传回原始数据库。移动
将WAL文件事务返回到数据库中称为
检查点。
Of course, one wants to eventually transfer all the transactions that are appended in the WAL file back into the original database. Moving the WAL file transactions back into the database is called a "checkpoint".
另一种方式来考虑回滚和
预写日志是在rollback-journal方法中，有
两个原始操作，读和写，而使用
预写日志，现在有三个原始操作：读取，
写入和检查点。
Another way to think about the difference between rollback and write-ahead log is that in the rollback-journal approach, there are two primitive operations, reading and writing, whereas with a write-ahead log there are now three primitive operations: reading, writing, and checkpointing.
默认情况下，SQLite在WAL文件
达到1000页的阈值大小时自动执行检查点。 （
SQLITE_DEFAULT_WAL_AUTOCHECKPOINT编译时选项可用于
指定不同的默认值。）使用WAL的应用程序不必执行
任何操作，以便发生这些检查点。但是如果他们想要
，应用程序可以调整自动检查点阈值。或
，他们可以关闭自动检查点，并在
空闲时刻或在单独的线程或进程中运行检查点。
By default, SQLite does a checkpoint automatically when the WAL file reaches a threshold size of 1000 pages. (The SQLITE_DEFAULT_WAL_AUTOCHECKPOINT compile-time option can be used to specify a different default.) Applications using WAL do not have to do anything in order to for these checkpoints to occur. But if they want to, applications can adjust the automatic checkpoint threshold. Or they can turn off the automatic checkpoints and run checkpoints during idle moments or in a separate thread or process.
这篇关于删除sqlite的WAL文件是否安全？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！