Поводом к написанию данной статьи, послужило падение базы во время сохранения конфигурации, при динамическом обновлении. Казалось бы сколько уже раз предупреждали - «Не делайте динамическое обновление на 8.2!», но иногда, без него просто не обойтись.
При динамическом обновлении, в процессе сохранения конфигурации, вылетела база 1С и отказалась заходить в режим Конфигуратора, выдавая сообщение «Внимание!!! При обновлении данных, после последней реструктуризации, произошла ошибка. Повторить обновление?», если ответить утвердительно, то появлялось сообщение «Обнаружена незавершенная операция сохранения конфигурации. Для продолжения работы необходимо завершить операцию.», после чего Конфигуратор закрывался.
Итак ничего не предвещало беды, но вдруг во время сохранения конфигурации, 1С выдала ошибку про поврежденный Config и благополучно закрылась. Думая, что проблема решится очень просто, я заново открыл Конфигуратор и прочитал следующее сообщение:
«Внимание!!! При обновлении данных, после последней реструктуризации, произошла ошибка. Повторить обновление?» «Да, Нет»
Все еще пребывая в радостном расположении духа, я нажал на "Да". 1С-ка немного задумалась и выдала новое сообщение:
«Обнаружена незавершенная операция сохранения конфигурации. Для продолжения работы необходимо завершить операцию.»
И после нажатия на кнопку «Ок» это окно закрылось вместе с конфигуратором. Вот тут-то я и начал подозревать, что все будет не так просто.
Бэкап, конечно же имелся, но с одним нюансом - больше чем за половину дня, 2000 пользователей, сделали кучу документов и прочей полезной работы, а бэкап был только по состоянию на утро, да и восстановление базы, размером более 100 Гб, занимает ну очень продолжительное время.
Продолжая копать глубже, я узнал, что все дело в "испортившихся" таблицах dbo.Config и dbo.ConfigSave.
Итак, отставить панику!Проверяем есть ли у нас конфигурация идентичная рухнувшей. В моем случае, их было целых 4, так как работаем через Хранилище Конфигурации. Можно использовать и не совсем идентичную конфигурацию, но будьте готовы к тому, что тогда все изменения придется вносить заново (если конечно у вас нет Хранилища Конфигурации).
Далее заходим в SQL Management Studio и очищаем таблицы dbo.Config и dbo.ConfigSave рухнувшей базы с помощью нехитрого запроса (для того чтобы его написать, нажмите "New Query" или "Новый Запрос", ну а чтобы выполнить - "Execute" и "Выполнить" соответственно):
Truncate table dbo.Config
Truncate table dbo.ConfigSave
Все, теперь осталось "залить" эти же таблицы из хорошей конфигурации. Как я уже написал выше, способ предложенный VanDiesel1 мне не помог, так как рабочая база и все базы с хорошими конфигурациями, находились в разных кластерах. Почитав мануал к SQL Management Studio, я наткнулся на такую возможность, как импорт таблиц из одной базы в другую и незамедлительно решил ей воспользоваться. Итак в SQL Management Studio становимся на испорченную базу и щелкаем правой кнопкой мыши, далее Tasks -> Import Data.
Откроется визард в котором:
- На второй странице указываем сервер и базу из которой мы будем брать данные.
- На третьей указываем базу приемник.
- На четвертой выбираем "Копировать данные из таблиц".
- На пятой отмечаем галками таблицы dbo.Config и dbo.ConfigSave.
- На шестой смотрим, чтобы не было ошибок и процесс загрузки прошел успешно.
Вот собственно и все, можно пробовать запускать 1С.
P.S. В ходе поиска решения узнал, что этот способ восстановления, является недокументированным 1С и все действия, вы выполняете на свой страх и риск, а документированный способ - это восстановление из бэкапа.
Надеюсь эта статья, кому-нибудь поможет сэкономить время и нервы. Также напоминаем что в нашем облаке 1С имеется бесплатное резервное копирование, которое защитит Вас от потери данных.