核心数据崩溃-NSPersistentStoreCoordinator没有持久性存储（损坏的文件）

Question

我看到一些带有该标题的崩溃报告：

NSPersistentStoreCoordinator没有永久存储（损坏的文件）。它无法执行保存操作。将永久存储添加到协调器的代码在这里：

    NSURL *applicationDocumentsDirectory = [[NSFileManager defaultManager] URLsForDirectory:NSDocumentDirectory inDomains:NSUserDomainMask].lastObject;

    NSURL *storeURL = [applicationDocumentsDirectory URLByAppendingPathComponent:@"myDatabase.sqlite"];

    NSURL *modelURL = [[NSBundle mainBundle] URLForResource:@"myDataModel" withExtension:@"momd"];

    NSManagedObjectModel *managedObjectModel = [[NSManagedObjectModel alloc] initWithContentsOfURL:modelURL];

    NSDictionary *storeOptions = @{NSInferMappingModelAutomaticallyOption:@YES,
                                   NSMigratePersistentStoresAutomaticallyOption:@YES,
                                   NSSQLitePragmasOption:@{@"synchronous": @"OFF"}};

    // Create the persistent store.
    self.persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:managedObjectModel];
    NSError *error = nil;
    if (![self.persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType
                                                       configuration:nil
                                                                 URL:storeURL
                                                             options:storeOptions
                                                               error:&error])
   {

    }

我已经记录了来自“ addPersistentStoreWithType”调用的错误，它是以下内容：

NSCocoaErrorDomain 259
NSSQLiteErrorDomain = 11;
NSUnderlyingException = "Fatal error. The database at <path> is corrupted. SQLite Error code:11, 'database disk image is malformed'

我认为这意味着核心数据库是不可恢复的。是这样吗 我有一个备份计划，要求破坏核心数据库并从服务器中重新填充它，但是我想知道它是否绝对不可恢复，以及是否有任何办法可以弄清楚为什么它可能首先发生了。

一些其他信息：

崩溃报告记录了运行iOS 10的RAM Free 3-6％，Disk Free 57％，较新型号的手机。开始看到这些报告的应用程序版本也是第一个将轻量级核心数据迁移作为其一部分的版本，我不确定这是否有所作为。我确实知道98％的用户已成功升级到该版本，并且进行迁移没有问题。这是报告中的堆栈跟踪。尽管它说“ device_locked”，但我知道即使我尝试将其保存到永久性存储中，即使用户在应用程序中，也会发生此崩溃。

Answer 1

1. 看看在没有同步编译指示的情况下是否可以获得可接受的性能。如果它对你没有多大帮助，那么就没有必要冒这个机会。

2. 我看到你已经有了可以有效检测问题何时发生的代码...当你遇到这种情况时，你可以通过简单地删除 SHM 和 WAL 文件来查看会发生什么。很可能只是那些搞砸了的人。

3. 如果您确实能够从服务器数据中恢复，并且这种情况确实很少发生，那么按照您所说的操作并删除整个数据库也许是可以接受的（如果＃2 没有帮助）。

4. 确保您在主线程上创建存储，并确保迁移在主线程上进行。