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