Внимание!!! При обновлении данных, после последней реструктуризации, произошла ошибка. Повторить обновление? Аварийное завершение обновления конфигурации базы данных С, восстановление конфигурации информационной базы с использованием MS SQL

Песочница

1С, восстановление конфигурации информационной базы с использованием MS SQL

В свое время столкнулся с проблемой: при обновлении конфигурации из хранилища, произошел сбой, и закрылась 1С.

Как выяснилось позднее – произошло разрушение хранилища конфигурации и при обновлении конфигурации из хранилища слетела и конфигурация БД. Подобная ошибка возникала прежде при динамическом обновлении ИБ.

Т.к. данная проблема возникала не однократно решил поделится вариантом лечения.

При следующем запуске конфигуратора вышла ошибка: «Внимание!!! При обновлении данных, после последней реструктуризации, произошла ошибка. Повторить обновление?» при утвердительном ответе получаем сообщение: «Обнаружена незавершенная операция сохранения конфигурации. Для продолжения работы необходимо завершить операцию» после этого приложение закрывается.

При разборе данной проблемы было найдено несколько вариантов решения проблемы, каждое решение работает в разных случаях.

Вариант 1 (при наличии бэкапа SQL c копией с идентичной конфигурацией):

Разворачивается копия ИБ, и выполняется запрос следующей конструкции:
USE GO DELETE FROM .. GO INSERT INTO .. SELECT * FROM .. GO
При этом пере заливается таблица в которой хранится конфигурация ИБ. Желательно после данной операции выполнить тестирование и исправление ИБ.

Вариант 2 (при отсутствии бэкапа):

К данному варианту обратились как к последней соломинке. Т.к. конфигурация была в стадии разработки и про бэкап немного позабыли понадеясь на хранилище.
В базе удаляются две записи из таблицы «Config» по значению в столбце «FileName» - dbStruFinal и commit

Выполняется следующий запрос:
USE GO DELETE FROM . WHERE FileName = "dbStruFinal" GO DELETE FROM . WHERE FileName = "commit" GO
Как ни странно база оживает.

Теги: 1с предприятие 8.2, SQL, восстановление конфигурации

Данная статья не подлежит комментированию, поскольку её автор ещё не является полноправным участником сообщества. Вы сможете связаться с автором только после того, как он получит

Переезжали мы на новый сервер. На нем SQL и 1C. В сравнении со старыми был намного круче. И тест Гилева это тоже подтвердил: против 10-15 на старых серверах выдавал 39. Поэтому мы сразу после покупки перенесли базу и начали работу.

Но в какой-то момент что-то пошло не так — пользователи стали жаловаться на медленную работу. Произвели определенные настройки сервера и служб (какие — тема отдельного поста) и решили перезагрузить сервер, благо скорость перезагрузки — 2 минуты (на других серверах до 10 доходило). После этого при входе в 1С получаем следующее сообщение:

«Внимание!!! При обновлении данных, после последней реструктуризации, произошла ошибка. Повторить обновление?» «Да, Нет»

После нажатия кнопки «Да» появляется следующее:

«Обнаружена незавершенная операция сохранения конфигурации. Для продолжения работы необходимо завершить операцию.»

Первое, что решил сделать — CHECKDB на в Managment Studio — после 2х часов ожидания (база 500 ГБ) — все ОК.

На просторах сети нашел информацию, что такая же ошибка бывает при динамическом обновлении.

Решения, предложенные в сети сходу не помогли, но вкупе с другими действия дали результат. Итак, что я делал:

Решение:

1. То, чего не хватало для решений из сети:

sp_configure ‘allow updates’, 1
reconfigure with override
go

2. Переводим базу в режим восстановления

alter database set EMERGENCY, SINGLE_USER

3. Выполняем тестирование базы:

dbcc checkdb(‘db_name’, REPAIR_ALLOW_DATA_LOSS)

4. Выводим базу из режима восстановления:

alter database set ONLINE, MULTI_USER

5. В принципе, если уверены что с самой базой все ок, то можно не делать 2-4 пункты. Далее выполняем два запроса в профайлере SQL:

delete from config where FileName = ‘commit’
delete from config where FileName = ‘ dbStruFinal’

Эти записи и отвечают за динамическое обновление — можно не бояться их удалять.

В рабочих версиях баз запросы:

select * from Config WHERE FileName = ‘commit’

select * from Config WHERE FileName = ‘dbStruFinal’

будут пустые.

6. возвращаем настройки:

sp_configure ‘allow updates’, 0
go

7. После этого удалось запустить конфигуратор и база заработала.

Также база может заработать после удаления первого флага.

Проблема, которой посвящена статья, возникает при аварийном завершении работы конфигуратора в тот момент, когда происходит реструктуризация базы данных, то есть - на одном из последних этапов обновления конфигурации. Решение, описанное в статье, относится к клиент-серверной версии платформы "1С: Предприятие", использующей в качестве СУБД "MS SQL Server".

Симптомами могут служить следующие предупреждения системы:

1)При попытки запуска базы в режиме конфигуратора:

2)При попытки запуска базы в режиме предприятия:

3)При входе в конфигуратор система может также предложить следующее решение:

На данный вопрос мы можем ответить утвердительно. И часто таким способом проблема решается. Но не всегда.

На наше согласие продолжить обновление система может ответить следующим сообщением:

Или же потребовать монопольного доступа, что не всегда удобно в системах с большим количеством пользователей, а иногда и просто невозможно.

В этом случае нам поможет MS SQL Server. Для решения нашей проблемы достаточно последовательно выполнить следующие скрипты (разумеется в контексте проблемной БД).

1) Сначала создадим копии таблиц Config и ConfigSave (впоследствии, их можно удалить).

SELECT *

INTO Config _ copy

FROM [ Config ]

SELECT *

INTO ConfigSave_copy

FROM

В данных таблицах, как раз, и хранится информация о конфигурациях и ходе обновления. В первой таблице хранится информация о конфигурации БД, в том числе, и данные последнего обновления. Вторая таблица содержит данные новой, ещё несохраненной конфигурации. Анализируя содержание этих таблиц, система получает данные о том, насколько успешным (или неуспешным) было последнее обновление.

2)Удаляем все записи из таблицы ConfigSave (хранит накатываемую конфигурацию)

DELETE FROM

3)Удаляем три записи из таблицы Config (именно они хранят информацию о незаконченном процессе обновления конфигурации)

DELETE FROM

WHERE FileName IN ("commit" , "dbStruFinal" , "dynamicCommit" )

В таблице Config должны появиться записи о нашем последнем обновлении, что легко проверить обычным «селектом».