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

Переезжали мы на новый сервер. На нем 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. После этого удалось запустить конфигуратор и база заработала.

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

Песочница

Железный человек 18 сентября 2013 в 15:24

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, восстановление конфигурации

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

Приветствую Вас, дорогие читатели.

Совсем недавно мне пришлось восстанавливать базу «1С предприятие 8» после падения, которое произошло во время обновления конфигурации. Причем это было дважды и методы примененные при восстановлении тоже были разными (скоро узнаете почему). В данной статье я хочу рассказать о тех способах, которыми я воспользовался.

Все способы рассматриваемые в статье относятся к серверному варианту работу «1С предприятие 8», используемое СУБД — MS SQL 2005.

Случай №1.

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

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

Поиски на просторах интернета выдали следующий способ. В таблице Config нашей базы данные необходимо удалить строки где поле FileName = commit или FileName = dbStruFinal или FileName=DynamicallyUpdated (для 8.3) или FileName=dynamicCommit (8.3) , а также очистить таблицу ConfigSave . Поясню за что отвечают данные таблицы: Config — в данной таблице хранится конфигурация базы данных, ConfigSave — в данной таблице хранится рабочая конфигурация, т.е. до нажатия кнопки F7 в конфигураторе.

Открываем SQL Serger Managment Studio и открываем окно запросов по кнопке «New Query » открывает окно запросов.

В окне запросов пишем запросы и выполняем их:

  1. delete from [ИмяНашейБазы].. where FileName = ‘commit’
  2. delete from [ИмяНашейБазы].. where FileName = ‘dbStruFinal’
  3. delete from [ИмяНашейБазы].. where FileName = ‘DynamicallyUpdated’ (для версии 8.3)
  4. delete from [ИмяНашейБазы].. where FileName = ‘dynamicCommit’ (для версии 8.3)
  5. delete from [ИмяНашейБазы]..

После выполнения данных запросов, конфигуратор запустился без проблем.

Случай №2

Причина ошибки входа в конфигуратор такая же как и в первом случае: конфликт блокировок при обновлении конфигурации.

Удаление строк в таблице Config и очистка таблицы ConfigSave помогло частично: конфигуратор открывался, но в предприятии не работали управляемые формы .

В данном случае приходило в голову 2 пути развития:

  1. Восстановление из архива. В данном варианте было одно большое «НО»: так получилось что архив создался уже после обновления, т.е. архив был с ошибкой.
  2. Была идея использовать конфигурацию распределенной базы, которая не обновилась, потому что файл для обмена был с ошибкой.

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

  1. Открываем SQL Serger Managment Studio и создаем произвольную базу, например Perenos. В этой базе создаем таблицу Config. Кто не знает sql для переноса данных из одной таблицы в другую, то у MS SQL есть замечательный сервис «SQL Server import and Export Wizard «. С помощью данного сервиса можно легко переносить данные из одной базу в другую. Чтобы запустить данный сервис необходимо нажать клавиши «ctrl+r » и в окне диалога написать команду «dtswizard «.
  2. Переносим с помощью сервиса dtswizard данные таблицы Config нашей базы в таблицу Config базы Perenos .
  3. Очищаем таблицу Config в нашей базе с помощью запроса delete from [ИмяНашейБазы]..
  4. На сервере, где находится распределенная база запускаем сервис dtswizard и переносим данные из таблицы Config в такую же таблицу только в нашей базе.

Вот с помощью таких действий получилось быстро и с минимальным простоем восстановить работоспособность базы.

Проблема, которой посвящена статья, возникает при аварийном завершении работы конфигуратора в тот момент, когда происходит реструктуризация базы данных, то есть - на одном из последних этапов обновления конфигурации. Решение, описанное в статье, относится к клиент-серверной версии платформы "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 должны появиться записи о нашем последнем обновлении, что легко проверить обычным «селектом».