Случилась сегодня ситуация: при обновлении конфигурации базы данных конфигуратор вывалился с ошибкой (суть которой не важна, да и не записали). После этого вход в базу стал невозможен: при попытке открыть её и клиентом, и конфигуратором, получили ошибку "Запись не найдена в менеджере имен базы данных".
Ситуацию усугубляло то, что бэкап перед обновлением, естественно, виновники торжества не сделали, последний бэкап датируется прошлой ночью, и за почти сутки десятки пользователей внесли сотни документов.
Зачем я пишу об этом? Затем, что в решении этой проблемы Гугл оказался не помощник:
- Гуглится огромная куча статей, где при аналогичной ошибке рекомендуется использовать утилиту восстановления файловых баз. А у них -- серверная.
- Гуглится огромная куча статей, где подобная ошибка возникает спорадически или при реструктуризации в результате каких-то манипуляций в расширении. В результате заход в конфигуратор и некие манипуляции там всё решают. А в нашем случае в конфигуратор зайти нельзя совсем.
- Что такое "менеджер имён базы данных", в какой таблице БД он хранится? Прямого ответа на этот вопрос Гугл не даёт.
- Есть несколько записей на разных форумах, когда человек столкнулся с такой же проблемой, ему советуют восстановить таблицы config, dbschema, files и т. п., но никакой информации о решении проблемы в итоге нет.
Итак, решение:
- Делаем копию битой базы при помощи pg_dump и куда-нибудь откладываем. Пока база бэкапится, виновнику торжества посылаем одну из картинок "Он не делал бэкапы".
- Разворачиваем из копии предыдущий ночной бэкап.
- "Менеджер имён базы данных" -- это данные, помимо прочих, хранящиеся в таблице params. Вот её нам и надо перетянуть из старого бэкапа в битую базу. Делаем дамп таблицы в развёрнутом бэкапе, очищаем таблицу в битой базе и загружаем из дампа.
Ответы на вопросы "как сделать дамп базы данных", "как сделать дамп отдельной таблицы", "как удалить содержимое таблицы" и "как загрузить данные из sql-дампа" в PostgreSQL Гугл уже знает достаточно хорошо.
Разумеется, эти советы надо применять осознанно и с умом. Возможно, параллельно стоит перетащить таблицу config. Также в нашем случае мы точно знали, что никаких других изменений в конфигурации между бэкапом и поломкой не происходило. Иначе можно получить разнообразные глюки.
Так как бэкапы -- наше всё, после восстановления имеет смысл сделать ещё один бэкап, запустить тестирование-исправление. А потом вообще развернуть чистую базу на той же конфигурации и перенести туда данные, например, через выгрузку-загрузку XML.
