1с ошибка после динамического обновления

Ошибки после динамического обновления ☑ 0

miron16

19.06.13

✎

08:21

Ошибки после динамического обновления. Перечитал много форумов. На инфостарте нашел статью в которой рекомендуется удалить строку в таблице SQL и перезапустить конфигуратор. так и сделал. Теперь Конфигуратор каждый раз предлагает динамически обновить конфигурацию базы при запуске, пишет что все ок и требуется перезагрузить конфигуратор….при запуске вываливается с ошибкой, записью дампа и все по новому…

Как запустить конфигуратор?

1

ICWiner

19.06.13

✎

08:24

2

ICWiner

19.06.13

✎

08:25

Ну и почисти таблицу dbo.ConfigSave, там лежит типа измененная конфигурация

3

ICWiner

19.06.13

✎

08:26

Хотя не совсем такая… Но попробовать стоит. И, конечно же, ты перед тем как что-то пробовать сделал выгрузку средствами скуля?..

4

miron16

19.06.13

✎

08:27

dbo.ConfigSave — пустая

5

miron16

19.06.13

✎

08:28

скулевый бекап конечно же сделал

6

Vovan_Magadan

19.06.13

✎

08:28

(0) что именно вызвало ошибку?

То-есть типа все время ДО было норм, сегодня фаза луны криво встала и ДО убило базу?

7

ICWiner

19.06.13

✎

08:29

Берешь еще рабочий бекап с такой же конфигурацией и копируешь dbo.Config из нее в свою. По ссылке в (1) все расписано

8

ICWiner

19.06.13

✎

08:29

Попробуй так

9

Vovan_Magadan

19.06.13

✎

08:30

(7) да… особенно это забавно делать в Файловом режиме, через HEX редактор

10

ICWiner

19.06.13

✎

08:30

Я пока боролся с результатом ДО чуть не поседел… Теперь только обычные обновления ночью. В крайнем случае в обед всех пользователей выгоняю

11

ICWiner

19.06.13

✎

08:31

(9) в (0) «На инфостарте нашел статью в которой рекомендуется удалить строку в таблице SQL и перезапустить конфигуратор. так и сделал.» Что как бэ намекает на клиент-сервер…

12

miron16

19.06.13

✎

08:31

нет последнего рабочего бекапа с текущей конфой

13

ICWiner

19.06.13

✎

08:32

Ну то что ты динамически менял — ты не структуру данных менял, так что и оно пойдет. Ночной конфигг есть?

14

miron16

19.06.13

✎

08:32

конфиг есть 2х дневный

15

ICWiner

19.06.13

✎

08:33

После этого реквизиты/документы добавлял?

16

miron16

19.06.13

✎

08:34

не уверен….

17

miron16

19.06.13

✎

08:34

но если и добавлял — то если они пропадут — ничего страшного

18

ICWiner

19.06.13

✎

08:35

Ну на копии грех не попробовать

19

shuhard

19.06.13

✎

08:47

(14) ну и что мешает взять Cf двухдневной давности и выгрузитьбзвгрузитьчерезxml ?

20

miron16

19.06.13

✎

09:10

shuhard — так и делаю =)

21

shuhard

19.06.13

✎

09:12

(19) хотя я в таких случаях переношу dbo.ConfigSave из базки в базку, но выгрузка полезна, битые ссылки почистяться =)

22

ICWiner

19.06.13

✎

09:14

(21) Дык если ConfigSave пустая… И смысл ее переносить, там же не примененные изменения

23

shuhard

19.06.13

✎

09:15

(22) в бэкапе двухдневной давности пустая — оооооооооооооооооооооооооооо

24

ICWiner

19.06.13

✎

09:19

А почему она должна быть заполненной? Возможно, таки, я не правильно понимаю… Там же хранятся изменения, которые еще не применены в конфигурацию? Или глупость говорю?

25

ICWiner

19.06.13

✎

09:20

Ну в смысле сохранены, но действие «Обновить конфигурацию бд» еще не выполнялось

26

Serg_1960

19.06.13

✎

09:52

27

miron16

19.06.13

✎

10:23

dynamicCommit  — вот что мешало!!!!  СПАСИБО!!!

Обнаружена незавершенная операция сохранения конфигурации

Динамическое обновление — это, конечно, нехорошо, но порой других возможностей просто нет. К примеру, компания, работающая 24/7 с количеством людей, работающих в базе, от 100 человек. Когда всех выгнать из базы и провести обновление очень затратно и необходимо заранее это согласовывать, тогда приходится использовать динамическое обновление. Сама ошибка заключется в том, что в момент записи в таблицу «Config» что-то произошло, что помешало корректно закончить данную процедуру. И существует два основных способа лечения этой проблемы:

— Первый — это удалить записи о том, что конфигурация обновлялась (не рекомендую, так как у меня не всегда корректно работало).

— Второй способ — перезаписать все данные в таблицы «Config»  из резервной копии вашей рабочей базы.

Второй способ более надежный, но была проблема в том, что необходимо было поднимать и разворачивать SQL-ный  бэкап, что занимало много времени.

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

Создал внешнюю обработку с двумя кнопками «Сохраниться перед динамическим обновлением»  и «Восстановить данные после ошибки динамического обновления».

Копка  «Сохраниться перед динамическим обновлением»   вызывает процедуру:

Процедура Сохраниться()
//Подключение к SQL
Connection=Новый COMОбъект("ADODB.Connection");
Connection.ConnectionTimeOut =600;
Connection.Open("Provider=SQLOLEDB.1;Password=Пароль;Persist Security Info=True;User ID=Пользовать;Initial Catalog=SQL_ИмяБазы;Data Source=SQL_Сервер");
RecordSet=Новый COMОбъект("ADODB.Recordset");
RecordSet.CursorLocation=3;
RecordSet.LockType=2;
Запрос="[master].[dbo].[sp_backup_config_tables]";
RecordSet.Open(Запрос, Connection);
//Сохраняем информацию о последнем обновлении
СтруктураДанных=Новый Структура();
СтруктураДанных.Вставить("Пользователь",ПараметрыСеанса.ТекущийПользователь);
СтруктураДанных.Вставить("ДатаСохранения",ТекущаяДата());
СтруктураДанных.Вставить("ИмяСервера",ИмяКомпьютера());
ЗначениеВФайл (ПолноеИмяФайла,СтруктураДанных);

ТекстИзменений="";

Запрос="SELECT  [FileName] FROM [SQL_ИмяБазы].[dbo].[ConfigSave]";;
RecordSet.Open(Запрос, Connection);
Если RecordSet.RecordCount>0 Тогда
RecordSet.MoveFirst();
Пока НЕ RecordSet.EOF() Цикл;
ТекстИзменений=ТекстИзменений+Символы.ПС+строка(RecordSet.Fields(0).Value);
RecordSet.MoveNext();
КонецЦикла;
КонецЕсли;
RecordSet.Close();
Сообщить("Данные сохранены. Будут изменены таблици:"+ТекстИзменений);
КонецПроцедуры

Копка  «Восстановить данные после ошибки динамического обновления»   вызывает процедуру: 

Процедура Восстановить ()
//Подключение к SQL
Connection=Новый COMОбъект("ADODB.Connection");
Connection.ConnectionTimeOut =6000;
Connection.Open("Provider=SQLOLEDB.1;Password=Пароль;Persist Security Info=True;User ID=Пользовать;Initial Catalog=SQL_ИмяБазы;Data Source=SQL_Сервер");
Command = Новый COMОбъект("ADODB.Command");
Command.ActiveConnection = Connection;
Command.CommandText ="[master]. [dbo].[sp_restore_config_tables]";
Command.CommandType = 1;
RecordSet = Новый ComОбъект("ADODB.RecordSet");
RecordSet.CursorType = 3;
RecordSet.LockType = 2;
RecordSet = Command.Execute();
КонецПроцедуры

[master].[dbo].[sp_backup_config_tables] и [master]. [dbo].[sp_restore_config_tables] 

Это процедуры в SQl.

[master].[dbo].[sp_backup_config_tables]

SET ANSI_NULLS OFF
GO
SET QUOTED_IDENTIFIER OFF
GO
/*
** The system profile of the same type of agent will be used as a template for
** the parameters in this new user profile.
*/
ALTER procedure [dbo].[sp_backup_config_tables]
AS  SET NOCOUNT ON

truncate table [dbo].[Config_Backup];

truncate table [dbo].[ConfigSave_Backup];

insert into [dbo].[Config_Backup]
select * from SQL_ИмяБазы.[dbo].[Config];

insert into [dbo].[ConfigSave_Backup]
select * from SQL_ИмяБазы.[dbo].[ConfigSave];

[master]. [dbo].[sp_restore_config_tables]

USE [master]
GO
/****** Object:  StoredProcedure [dbo].[sp_restore_config_tables]    Script Date: 01/22/2023 11:48:09 ******/
SET ANSI_NULLS OFF
GO
SET QUOTED_IDENTIFIER OFF
GO
/*
** The system profile of the same type of agent will be used as a template for
** the parameters in this new user profile.
*/
ALTER procedure [dbo].[sp_restore_config_tables]
AS
SET NOCOUNT ON

truncate table SQL_ИмяБазы.[dbo].[Config];

truncate table SQL_ИмяБазы.[dbo].[ConfigSave];

insert into SQL_ИмяБазы.[dbo].[Config]
select * from [dbo].[Config_Backup];

insert into SQL_ИмяБазы.[dbo].[ConfigSave]
select * from [dbo].[ConfigSave_Backup]; 

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

Если раньше такая ошибка считалась критичной и время восстановления занимало до 1 часа, то теперь оно сократилось до 5 минут.  

Update :

Статья о триггере , для сохранения таблицы Config перед обновлением //infostart.ru/public/327674/

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

Данная проблема я не встречал ни разу на платформе 8.3

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

Поиск решения вопроса в интернете дал мне надежду. Очень помогла статья на сайте 42clouds  Незавершенная операция обновления конфигурации БД

Как известно, вся информационная база представляется в базе данных в виде набора таблиц. Среди них есть несколько таблиц, которые обязательно присутствуют в представлении любой информационной базы ( подробнее можно посмотреть на диске ИТС Размещение данных 1С:Предприятия . Из всех этих таблиц для нас имеет значения только 2 таблицы из них:

•  dbo.Config  –  основная конфигурация информационной базы. Эта конфигурация соответствует реальной структуре данных и используется 1С:Предприятием 8.0 в режиме Предприятия данные переносятся в эту таблицу  после обновления
• dbo.ConfigSave –  конфигурация, редактируемая Конфигуратором. Конфигурация из ConfigSave переписывается в Config при выполнении “Обновления конфигурации базы данных” в Конфигураторе, а наоборот – при выполнении в Конфигураторе операции “Конфигурация – Конфигурация базы данных – Вернуться к конфигурации БД”

Согласно информации в интернете проблема   связана с испорченной таблицей dbo.Config и предлагается 2 варианта решения:

Вариант 1: Воспользоваться возможностью скопировать таблицу dbo.Config из идентичной базы в неработающую 

Вариант 2  Удалить все найденные изменения. Для этого вам необходимо выполнить 3 запроса:

1.  delete from config where FileName = ‘commit’
2. delete from config where FileName = ‘dbStruFinal’
3. delete from config where FileName = ‘dynamicCommit’

Я выполнил все 3 запроса, но говоря, что иногда достаточно выполнить только первый запрос.

В других статьях в интернете предлагают другой вариант по шагам:

1. Делать бэкап рухнувшей базы средствами SQL.
2. Очистить таблицу dbo.config рухнувшей базы SQL- Profiler запустить команду:

Use BaseName go Delete From [DBO].[Config] go

где BaseName – это имя рухнувшей базы.