При динамическом обновлении возник сбой. Программа осталась доступной для пользователей в режиме Предприятия, но конфигуратор перестал открываться.
Исходные данные: 1C Предприятие 8.3, клиент-серверная база, MS SQL 2012, резервное копирование настроено средствами MS SQL, бэкапы создаются 1 раз в сутки, ночью.
Конфигурация модифицированная и над ней ведется активная работа, поэтому у меня была вторая серверная база, в которой и велась разработка, плюс имелись в наличии выгрузки в dt из обеих баз на предыдущий день. В качестве имени рабочей базы в статье будет применено "MyBase", в качестве имени резервной серверной базы "MyTestBase"/
В моем случае таблица базы ConfigSave была пустой, как и в описанных материалах, а в таблицах Config и Params присутствовали строки со значением "DynamicallyUpdated" в поле FileName
Материалы из сети, которыми я пользовалась при решении вопроса:
https://forum.sys-adm.in/index.php?topic=558.0
http://1c-kod.ru/index.php?t_id=108
Заказчиком было принято решение о проведении восстановительных работ по окончанию рабочего дня с риском потери данных за текущий день (в случае провала процедуры восстановления и необходимости отката до ночного бэкапа).
Для решения проблемы были выполнены следующие действия:
1. Отключены все сеансы пользователей 1с
2. Через консоль управления 1с серверами установлена блокировка начала сеансов и отмена запуска регламентных заданий.
3. Сделан бэкап рабочей базы средвами MS SQL с использованием SQL Server Management Studio. Запросами из таблиц
удалены записи со значениями "DynamicallyUpdated" в поле FileName из таблиц Config и Params:
Delete From [MyBase].[dbo].[Config]
WHERE [FileName] LIKE 'DynamicallyUpdated'
и
Delete From [MyBase].[dbo].[Params]
WHERE [FileName] LIKE 'DynamicallyUpdated'
4. В резвервную базу средствами конфигуратора загружена последняя выгрузка .dt из рабочей базы (вечер предыдущего дня) и поверх загружена последняя рабочая конфигурация текущего дня из имеющегося файла .cf (вся история изменений конфигурации хранится в отдельных файлах с номерами версий)
5. В диспетчере задач пришлось отключить повисшие процессы 1с8
6. Остановлена служба сервера 1с
7. Очищен кэш 1С
В моем случае это было переименование папок C:\Users\Администратор\AppData\Local\1C\1сv8
C:\Users\Администратор\AppData\Roaming\1C\1CEStart
C:\Users\Администратор\AppData\Roaming\1C\1Cv82
C:\Users\Администратор\AppData\Roaming\1C\1Cv8
8. Запущена служба сервера
9. После чистки кэша окно со списком баз при запуске 1С пустое, поэтому добавляем существующую рабочую серверную базу
10. Открылся конфигуратор. Делаем на всякий случай выгрузку в .dt рабочей базы в текущем "сломанном" состоянии и закрываю конфигуратор
11. Запускаем SQL Server Management Studio и запросом очищаем в рабочей базе таблицу Config и перезаписываем ее содержимым аналогичной талицы из резервной базы:
Delete From [MyBase].[dbo].[Config]
INSERT INTO [MyBase].[dbo].[Config] SELECT * FROM [MyTestBase].[dbo].[Config]
У авторов использованных материалов (см. ссылки выше) после выполненных действий работоспособность базы была восстановлена. В моем случае на текущем этапе ошибка осталась, открыть окно базы в конфигураторе не представлялось возможным. Сравнив количество записей в таблицах Params рабочей и резервной баз, пришла к выводу, что стоит попробовать перезаписать и ее:
Delete From [MyBase].[dbo].[Params]
INSERT INTO [MyBase].[dbo].[Params] SELECT * FROM [MyTestBase].[dbo].[Params]
После чего мне удалось запустить конфигуратор и открыть окно с конфигурацией. Выгрузила на всякий случай в текущем состоянии в .dt и загрузила поверх последнюю рабочую конфигурацию текущего дня.
12. Отключаем блокировку начала сеансов и входим в режиме предприятия
Работоспособность полностью восстановлена, данные не потеряны.
13. Выключаем блокировку запуска регламентных заданий.
