Повреждение основных данных в хранилище sqlite после сбоя питания

Question

Я пишу простое приложение Какао в 10.6.Во время работы программы произошел сбой питания (программа периодически сохраняет данные в хранилище данных), и файл sqlite, используемый моей программой, каким-то образом поврежден.

Я создаю контекст управляемого объекта встандартным способом:

managedObjectContext = [[NSManagedObjectContext alloc] init];
[managedObjectContext setPersistentStoreCoordinator: coordinator];

и обычно все нормально, но на этот раз при чтении объекта:

NSLog(@"%@",dir.files);

получаю:

2011-06-03 11:33:38.079 Backup Check[1927:3c03] Relationship fault for 
(<NSRelationshipDescription: 0x100562230>), name files, isOptional 1, 
isTransient 0, entity Directory, renamingIdentifier files, validation 
predicates ( 
), warnings (
), versionHashModifier (null), destination entity File, inverseRelationship
directory, minCount 0, maxCount 0 on 0x10058bbc0

Iпопробовал инструмент sqlite3 в командной строке, и многие вещи можно прочитать правильно, но для некоторых операций чтения таблиц я получаю кучу записей таблицы, а затем:

SQL error: database disk image is malformed

Я предполагаю, что сбой питанияпроизошло именно во время сохранения.У меня есть пара вопросов: 1) Как я могу обнаружить / восстановить после этого?Прямо сейчас я не получаю никаких ошибок, которые я вижу, когда создается объектный контекст.Кроме того, многие из таблиц без ошибок, и только при углублении в подтаблицы я получаю эту ошибку отношения.Я не могу проверить ноль, потому что объект возвращается - это просто не NSSet.Это какой-то объект вины отношений.2) Как я могу предпринять шаги для предотвращения коррупции в будущем?Существует ли простой способ проверки согласованности при создании контекста управляемого объекта, и, если обнаружено повреждение, я могу вернуться к старой версии?В каталоге поддержки приложений я вижу только один файл, который является поврежденной базой данных.

Answer 1

Нет API-инструментов для восстановления поврежденного хранилища SQL. Это просто настолько редкое явление, что нет особого смысла. За последние 5 с лишним лет я видел только одно поврежденное хранилище Core Data SQL.

Распечатка, которую вы получаете из NSLog, не указывает на ошибку. Использование слова «ошибка» не означает ошибку в этом контексте, а скорее указывает, что это объект ошибки. Отказы - это легкие «призрачные» объекты, представляющие управляемые объекты в отношениях. Отказы используются для поддержания целостности графа объекта без необходимости загрузки всех данных, связанных с каждым объектом. Извлечения возвращают ошибки отношений по умолчанию, поэтому их видение в отношениях нормальное и не указывает на ошибку.

Ошибка SQL указывает, что схема для БД была повреждена. Не существует автоматического способа исправить это. Вам просто нужно выкинуть свои безумные навыки низкоуровневого SQL и снова соединить БД. Это редко стоит усилий, чтобы сделать это. (Во-первых, вам нужно разобраться с недокументированной схемой Apple.)

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

Эти виды коррупции настолько редки, что я бы не стал пытаться с ними бороться. Однако, если вы параноик, простым частичным решением будет периодически копировать файл хранилища в резервную копию, чтобы, по крайней мере, вы могли вернуться к предыдущей версии и не начинать все заново.