Ошибка "Запись не найдена в менеджере имен базы данных" с катастрофическими последствиями и её лечение

24.05.24

База данных - Администрирование СУБД

Ситуация: при обновлении серверной базы данных произошёл сбой и теперь невозможно войти ни в конфигуратор, ни в 1С:Предприятие по причине ошибки, вынесенной в заголовок. Рецепт лечения.

Случилась сегодня ситуация: при обновлении конфигурации базы данных конфигуратор вывалился с ошибкой (суть которой не важна, да и не записали). После этого вход в базу стал невозможен: при попытке открыть её и клиентом, и конфигуратором, получили ошибку "Запись не найдена в менеджере имен базы данных".

Ситуацию усугубляло то, что бэкап перед обновлением, естественно, виновники торжества не сделали, последний бэкап датируется прошлой ночью, и за почти сутки десятки пользователей внесли сотни документов.

Зачем я пишу об этом? Затем, что в решении этой проблемы Гугл оказался не помощник:

  1. Гуглится огромная куча статей, где при аналогичной ошибке рекомендуется использовать утилиту восстановления файловых баз. А у них -- серверная.
  2. Гуглится огромная куча статей, где подобная ошибка возникает спорадически или при реструктуризации в результате каких-то манипуляций в расширении. В результате заход в конфигуратор и некие манипуляции там всё решают. А в нашем случае в конфигуратор зайти нельзя совсем.
  3. Что такое "менеджер имён базы данных", в какой таблице БД он хранится? Прямого ответа на этот вопрос Гугл не даёт.
  4. Есть несколько записей на разных форумах, когда человек столкнулся с такой же проблемой, ему советуют восстановить таблицы config, dbschema, files и т. п., но никакой информации о решении проблемы в итоге нет.

Итак, решение:

  1. Делаем копию битой базы при помощи pg_dump и куда-нибудь откладываем. Пока база бэкапится, виновнику торжества посылаем одну из картинок "Он не делал бэкапы".
  2. Разворачиваем из копии предыдущий ночной бэкап.
  3. "Менеджер имён базы данных" -- это данные, помимо прочих, хранящиеся в таблице params. Вот её нам и надо перетянуть из старого бэкапа в битую базу. Делаем дамп таблицы в развёрнутом бэкапе, очищаем таблицу в битой базе и загружаем из дампа.

Ответы на вопросы "как сделать дамп базы данных", "как сделать дамп отдельной таблицы", "как удалить содержимое таблицы" и "как загрузить данные из sql-дампа" в PostgreSQL Гугл уже знает достаточно хорошо.

Разумеется, эти советы надо применять осознанно и с умом. Возможно, параллельно стоит перетащить таблицу config. Также в нашем случае мы точно знали, что никаких других изменений в конфигурации между бэкапом и поломкой не происходило. Иначе можно получить разнообразные глюки.

Так как бэкапы -- наше всё, после восстановления имеет смысл сделать ещё один бэкап, запустить тестирование-исправление. А потом вообще развернуть чистую базу на той же конфигурации и перенести туда данные, например, через выгрузку-загрузку XML.

См. также

Администрирование СУБД Системный администратор Программист

В крупных компаниях, где много типовых и сильно доработанных баз с режимом работы 24/7, переход с MS SQL на PostgreSQL затягивается. Получается гетерогенная структура – когда прод уже на PostgreSQL, а разработка и тестирование – пока на MS SQL. О том, какие варианты помогут постепенно перевести прод с несколькими базами MS SQL на PostgreSQL, не сломав среду тестирования и разработки, пойдет речь в статье.

21.11.2024    3175    a.doroshkevich    7    

15

Администрирование СУБД Системный администратор Платформа 1С v8.3 Бесплатно (free)

Пользовался ранее https://infostart.ru/1c/articles/1120161/#, но она устарела, т.к. службы запускаются через systemctl, да и сами службы слегка изменились. Возможно, где-то на ИТС уже есть нужная инструкция, но мне не попалась.

15.11.2024    426    Baser    2    

1

HighLoad оптимизация Администрирование СУБД Системный администратор Программист Платформа 1С v8.3 Россия Бесплатно (free)

Мы исследуем проблему долгого выполнения запросов PostgreSQL при использовании конструкции VALUES: когда она возникает, как на нее можно повлиять, а главное, почему ее продуманная отработка важна для более быстрого функционирования решений на базе 1С

12.11.2024    1073    Tantor    20    

15

HighLoad оптимизация Администрирование СУБД Механизмы платформы 1С Программист Платформа 1С v8.3 ИТ-компания Россия Бесплатно (free)

В данной статье мы рассмотрим, как работает механизм временных таблиц на postgres на платформе 8.3.23 и что изменилось в нем при добавлении новых возможностей в платформе 8.3.25. А также на примере покажу, как понимание работы платформы позволяет оптимизировать СУБД для работы с 1С.

29.10.2024    3686    Tantor    38    

35

Администрирование СУБД Системный администратор Программист Бесплатно (free)

CDC - очень мощный механизм, который можно использовать во многих сценариях, возможность развернуть его в Docker показывает простоту и лёгкость данной технологии.

08.10.2024    911    AlexSvoykin    1    

7

Администрирование СУБД Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Анализ и решение ошибок СУБД. Во время реиндексации базы Ошибка СУБД: Microsoft SQL Server Native Client 11.0: Не удалось найти объект "ИмяБазы.dbo._RefSInf21806", так как он не существует, или отсутствуют разрешения. Во время проверки целостности Ошибка СУБД: Microsoft SQL Server Native Client 11.0: Недопустимое имя объекта "dbo._RefSInf21806".

19.09.2024    4773    Xershi    10    

17

HighLoad оптимизация Администрирование СУБД Архивирование (backup) Системный администратор Программист Платформа 1С v8.3 Бесплатно (free)

Бэкап в Postgres состоит из набора граблей, которые нужно обойти для успешного восстановления. Они заложены в самых неожиданных местах от предмета резервного копирования (база или кластер) до структуры каталогов. Один неверный шаг и восстановление будет невозможным. Почему нельзя было сделать проще, как в MS SQL или Oracle? Почему бэкап в Postgres оставляет впечатление чьей-то лабораторной работы? Статья адресована прежде всего специалистам 1С, избалованным комфортом в MS SQL, в суровых буднях импортозамещения на Postgres.

13.08.2024    3121    1CUnlimited    9    

5
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. mrcamomile 83 24.05.24 14:34 Сейчас в теме
Спасибо, напишите в статье платформу на которой поймали эту ошибку.
3. Kernelbug 54 24.05.24 19:32 Сейчас в теме
(1) Не имеет значения. Ну 8.3.22.1750
2. SerVer1C 817 24.05.24 15:00 Сейчас в теме
Вы целиком перетягивали params или отдельные записи?
4. Kernelbug 54 24.05.24 19:33 Сейчас в теме
(2) Перетянул целиком, но потом пришел к выводу, что надо будет подробнее разобрать содержимое и переносить конкретные записи.
5. gurd 5 07.06.24 14:11 Сейчас в теме
Словил себе такую ошибку сегодня. При обновлении с реструктуризацией вылетела ошибка исключительной блокировки, не удалось завершить обновление. Эту ошибку полечил, вроде, заработало, но на некоторых запросах сыпалась ошибка Запись не найдена в менеджере имен базы данных.
В обновлении добавлялись несколько новых реквизитов, возможно, при реструктуризации эти новые реквизиты корректно в базу не записались, поэтому удалил добавленные реквизиты, сохранил изменения с реструктуризацией ИБ и ошибка исчезла.
Теперь при обновлении будем не только завершать сеансы пользователей, блокировать регламентные задания, но и стопать веб сервер на время обновления, чтобы ничего случайно не могло в базу подключиться.
6. Kernelbug 54 13.06.24 18:20 Сейчас в теме
(5) Конечно, в нормальной ситуации бэкапы рулят. Но если база такая, что восстановление из бэкапа занимает часов 5 и есть способы починить напрямую и быстрее, эти способы рулят тоже. Но бэкапы всё равно рулят.
7. paulwist 18.06.24 09:33 Сейчас в теме
(6)
"Менеджер имён базы данных" -- это данные, помимо прочих, хранящиеся в таблице params.


Как поймали (с помощью какого инструмента) имя таблички params??
8. Kernelbug 54 18.06.24 17:15 Сейчас в теме
(7) Гугл, глаза, сумбурная документация
9. gurd 5 21.06.24 03:20 Сейчас в теме
Сегодня снова получил себе такую ошибку. Никого в базе не было, регламентные задания заблокированы, веб сервер остановлен. По идее, никто не должен был помешать принятию изменений, но после появления сообщения с кнопкой "Принять", вылетает ошибка блокировки и конфигуратор вылетает. При попытке войти снова такая ошибка, конфигуратор недоступен. Почистил delete fr om Config WH ERE FileName = 'commit', в конфигуратор пустила, но в режиме клиента не проводились документы, опять там, где добавлял новые реквизиты: ошибка Запись не найдена в таблице имен...
Теперь уже одно удаление проблемных реквизитов с последующей реструктуризацией не прокатило, точнее после удаления проблемных реквизитов и попытке сохранить изменения вылетала ошибка, что не найдено поле и указано имя этого поля (так понял этот новый реквизит). Выполнил тестирование и исправление с включенными режимами: Пересоздание автономной конфигурации и Обновление размещения таблиц информационной базы. После этого дала выполнить удаление проблемных реквизитов и сохранить изменения с реструктуризацией, а потом повторил обновление, которое в первый раз не прошло, и все заработало.
Возможно, кто-то из пользователей пытался войти в 1С как раз в тот момент, когда нажал "Принять" при сохранении изменений.
Оставьте свое сообщение