#Что происходит и когда возникает
«malformed database schema» означает, что SQLite не может корректно разобрать часть схемы (например, CREATE TABLE, VIEW, TRIGGER или INDEX) либо база повреждена. Не каждое прерванное обновление реально повреждает файл: транзакционные изменения схемы SQLite обычно откатываются, но некорректный SQL, приложение с ручными правками sqlite_schema, потерянный журнал или неполная копия способны привести к проблеме. Нельзя исправлять её прямым UPDATE sqlite_schema или PRAGMA writable_schema=ON без независимой экспертизы.
#Возможные причины: как различить
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Ошибочное определение таблицы, представления или индексаSQLite не может разобрать SQL-описание объекта. | Сообщение может указывать конкретное имя объекта или near ... syntax error. | Проверить журналы миграции и сравнить схему с резервной копией. |
| Неполная копия или потерянные журналыПри копировании .db без -wal могли потеряться подтверждённые изменения. | Файл перенесён, журнал отсутствует, ошибка появилась после восстановления. | Сохранить все оригинальные файлы и искать согласованную резервную копию. |
| Повреждение страниц базыСбой накопителя или аварийный процесс мог нарушить физическую структуру. | PRAGMA integrity_check сообщает ошибки или сам не может выполниться. | Не писать в источник; работать с копией и проверенной процедурой восстановления. |
#Пошаговая диагностика и исправление
- Остановите запись в проблемную базуЕсли ошибка появилась сразу после обновления, прекратите новые операции записи штатным способом и запишите время, версию приложения и весь текст сообщения. Не запускайте миграцию повторно: она может усугубить состояние. Не меняйте структуру базы на работающем файле.
- Сохраните оригинал с учётом WAL и журналовЕсли база используется приложением, согласуйте остановку соединений или сделайте согласованный снимок файловой системы. Для потенциально повреждённой базы сохраните исходный файл, его существующие -wal/-shm/-journal и информацию о времени файлов как единый набор. Не стирайте и не переименовывайте журналы: они могут быть необходимы для автоматического восстановления.
- Сверьте точный файл и предыдущие миграцииВ журнале приложения найдите номер последней успешной миграции и команду, после которой появился malformed schema. Проверьте путь к SQLite-файлу: после смены рабочего каталога приложение могло открыть другую базу. Не объявляйте базу повреждённой только по одной записи журнала.
- Проверяйте исключительно копиюПодготовьте отдельную рабочую копию согласованным способом. Если она открывается, запустите PRAGMA integrity_check; и затем PRAGMA foreign_key_check;. Ожидается ok для первой проверки, пустые строки для второй. Если команда отказывает из-за повреждённой схемы, это диагностический результат: остановитесь, не пытайтесь менять system tables.
- Проверьте SQL-описания только при доступном чтенииЕсли SELECT из sqlite_schema выполняется, найдите проблемный объект по имени и сравните его CREATE SQL с последней исправной копией или миграционным файлом. Это чтение метаданных; не выполняйте UPDATE sqlite_schema. Если чтение падает, переходите к восстановлению из проверенного источника.
- Восстановите исправную базу в отдельном каталогеПри наличии резервной копии с известным временем и успешной проверкой разверните её вне рабочей директории и запустите приложение в тестовом режиме. Сравните ключевые таблицы, количество строк и контрольные идентификаторы. Согласуйте потери операций, выполненных после точки восстановления, прежде чем переключать пользователей.
- При отсутствии копии используйте восстановление только как последнюю возможностьКоманда sqlite3 .recover пытается извлечь данные из неповреждённых страниц в SQL-текст. Используйте её только на выделенной копии в отдельном каталоге и создайте новую базу; пример ниже — для администратора с опытом SQLite. Восстановленные строки могут быть неполными, содержать ранее удалённые значения или потерять связи; их необходимо отдельно проверять.
- Зафиксируйте окончательный результат и предотвратите повторениеПосле проверки восстановленной базы выполните тест штатных функций, повторите PRAGMA integrity_check, foreign_key_check и контроль данных. Если новая схема ошибочна, исправьте миграцию в коде и прогоните на копии, а не переписывайте внутренние записи SQLite. Добавьте резервное копирование Online Backup API и журналирование выпусков.
#Команды и проверочные примеры
PRAGMA integrity_check;PRAGMA foreign_key_check;sqlite3 damaged-copy.db ".recover" > recovered.sqlКоманда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.
sqlite3 newly-created.db < recovered.sqlЭта команда может привести к потере данных или существенным изменениям. Проверьте параметры, резервную копию и возможность отката.
#Как проверить результат
Проверенная база открывается, PRAGMA integrity_check выводит ok, foreign_key_check не показывает нарушений, приложение в тестовой среде запускается и контрольные записи соответствуют исходным требованиям. Сама успешная .recover не равна гарантированному восстановлению.
#Если не помогло
Если .recover пропускает таблицы, создаёт lost_and_found или находит несогласованные строки, остановите автоматический запуск и передайте эксперту копии и протокол восстановления. При аппаратной ошибке носителя сначала обследуйте сам накопитель, не повторяя интенсивные операции на оригинале.