Внимание при сохранении конфигурации произошла ошибка повторить сохранение

Сломалась база БП 3.0 ☑ 0

Balabass

15.01.15

✎

09:35

1

shuhard

15.01.15

✎

09:37

2

vde69

15.01.15

✎

09:37

3

polosov

15.01.15

✎

09:38

(0) Бекапы перед обновлением научить делать?

4

Cube

15.01.15

✎

09:39

(0) Стаж: 4 года 6 месяцев 11 дней

а копии перед обновлением делать не научился… Ну, теперь будешь умнее.

5

Balabass

15.01.15

✎

09:40

(1) Не в кеше дело.

(2) Жлобье оно и в африке жлобье.

Но интересуют варианты вытащить данные.

6

polosov

15.01.15

✎

09:40

(0)

Ну попробуй в chdbfl.exe проверить.

7

Balabass

15.01.15

✎

09:40

ВАЖНОЕ ПЫСЫ:

База не моя, контора не моя, я не при делах.

Позвонили, попросили посмотреть.

8

Кай066

15.01.15

✎

09:41

бэкап восстановить уже предлагали?

9

vicof

15.01.15

✎

09:42

(7) Думаешь, заплатят, если такие жмоты?))

10

vicof

15.01.15

✎

09:42

А бэкап восстановить советовали?

11

Cube

15.01.15

✎

09:42

(7) Мопед не мой, я просто разместил объяву)))))))))))))

12

Balabass

15.01.15

✎

09:43

(10) Бекап мертвее базы. Причем все мертвые.

(11) Именно так.

(9) Уверен что нет. Делают из спортивного интереса. Смогу или нет.

13

Кай066

15.01.15

✎

09:43

В БП 3 вроде как даже встроена автоархивация. даже если перед онбновлением не забэкапились, то можно взять бэкап за день до этого

14

Balabass

15.01.15

✎

09:44

(13) она автоматом настроена?

15

Balabass

15.01.15

✎

09:44

(13) Или колдовать нужно?

16

Cube

15.01.15

✎

09:45

(14) На сколько знаю, нет, надо настраивать.

17

Кай066

15.01.15

✎

09:45

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

18

Кай066

15.01.15

✎

09:46

(16) Обычно тот кто ставит прогу после установки ставит и настройки архивации. Если конечно не уборщица прогу ставила.

19

polosov

15.01.15

✎

09:46

(14) Если обновление было автоматическое, то бекап создавался. Поиск по *.dt поможет.

20

Balabass

15.01.15

✎

09:49

(18) Это под вопросом. )

(19) Архивы все мертвые. При загрузке «» Недостаточно фактических параметров, таблица _sys чегото там тратата»

21

Кай066

15.01.15

✎

09:49

хотя если ставил тот же, кто и обновлял))

22

Balabass

15.01.15

✎

09:49

(21) Вово

23

Balabass

15.01.15

✎

09:49

В компе блок питания на 200 ват и вентилятор сломан )

24

Кай066

15.01.15

✎

09:49

(20) тратата, в пустую базу пробовал разворачивать?

25

Balabass

15.01.15

✎

09:51

(24) Конечно.

Нашел архив от июля. Щас его развернул. попробую в него данные перелить новые.

26

Balabass

15.01.15

✎

11:24

Почему то выгрузка/загрузка черех ХМЛ не работает. База приемник говорит — неверный формат файла.

ДАйте кто нибудь выгрузку закгрузку между идентичными базами. Маней нет.

Желательно под УФ.

kurguzovvlad@gmail.com

27

Cube

15.01.15

✎

11:26

(26) Гуглится за 5 сек. Лентяй?

28

stix2010

15.01.15

✎

11:44

(23) зажмотились даже на комп?

29

stix2010

15.01.15

✎

11:55

(17)  БП3 постоянно на нервы действует сообщениями, если  архивация не настроена, проще настроить, чем смотреть на это.

30

Balabass

15.01.15

✎

11:58

(28) Оказались бюджетниками.

(27) То что гуглится, либо платное, либо не под УФ.

31

Cube

15.01.15

✎

12:04

(30) Стандартная обработка с ИТС на УФ и нагуглил я её быстро, когда диска не было под рукой…

32

Balabass

15.01.15

✎

12:12

(31) ВОт она мне при загрузке пишет — НЕВЕРНЫЙ ФОРМАТ ФАЙЛА ЗАГРУЗКИ.

33

pavelul73

15.01.15

✎

12:16

(32) Значит разные конфигурации

34

FullMoon

15.01.15

✎

12:25

Есть бесплатные утилиты для работы с таблицами ИБ. Битую таблицу конфигурации нужно заменить на целую таблицу конфигурации ИБ, а также почистить таблицу изменений конфигурации. Гугл в помощь.

35

Balabass

15.01.15

✎

12:36

(34) 1с тулз?

Я знаю что можно — только вот нужно больше инфы.

36

polosov

15.01.15

✎

12:46

(35) В chdbfl базу пробовал?

37

Balabass

15.01.15

✎

12:47

(36) да это 1 что я пробовал. База с 800 мгб в 500 превращается.

38

Кай066

15.01.15

✎

12:49

(37) и какой результат?

39

Balabass

15.01.15

✎

12:56

(38) Результат чека? не открывается ничего — ни пофигуратор, ни предприятие, лезут ошибки на вражеском наречии.

40

Balabass

15.01.15

✎

12:57

41

Balabass

15.01.15

✎

12:58

42

Balabass

15.01.15

✎

12:58

Файл не обнаружен ‘v8srvr://dbeng8/f06a5b5d8/configsave/0f9df01f-453a-47be-a793-b0a1254d2df9.0.new’

по причине:

Файл не обнаружен ‘ConfigSave\0f9df01f-453a-47be-a793-b0a1254d2df9.0.new’

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

Надеюсь эта статья, кому-нибудь поможет сэкономить время и нервы.

  Недавно,  при динамическом  обновлении конфигурации  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 – это имя рухнувшей базы.

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

Предистория

Два дня назад осуществили переход с 8.1 на 8.2 — меняли конфу УПП 1.2… на 1.3.22.1. Соответственно куча отличий от типовой конфигурации, которые накатывали — повлекло за собой кучу ошибок. Два дня, не ночуя, меняем конфигурацию в режиме нон-стоп. Конфигуратор сохраняется раз 15 в час. Следовало ожидать, что при сохранении, конфигурация может вылететь, что собственно и произошло. Такие проблемы, в конфе 8.1 — всегда разрешались выходом пользователей, которые еще работали в базе, но уже не могли повторно войти и монопольным доступом. В нашей же новой конфигурации 8.2 база сказала нам «Я устал. Я ухожуй» ), в общем проблема описана в анонсе.

Что было предпринято из правильного и неправильного. И совет о том что делать первым делом.

Первым делом мы в суматохе начинаем искать способы решения возникшей проблемы в интернете. Гугл дает буквально 3 статьи на текущий момент по тексту возникающей ошибки.

В общем во всех трех статьях ответ на решение текущий проблемы один — «Восстанавливайте базу из бэкапа».

Не стоит говорить о важности бэкапов их регулярности и прочем. Считаю что в плане нас это было хорошим предупреждением, хотя у нас и был бэкап базы после ее сохранения в конфигурации 1.3 но за их регулярностью и тем что они делаются (а винчестер не чистится и прочее) , за этим мало кто следит. Соответственно простите за «капитана очевидность», но если у вас есть свежий бэкап — первым делом и займитесь восстановлением базы из него, не теряйте драгоценное время, за простой которого руководство вас не поблагодарит. Однако можно попытаться оживить «упавшую» базу, что благодаря моей настырности было и предпринято. Отмечу, что другим программистом также были приняты попытки как то оживить базу 1с-вскими способами, но они были безуспешны. Не знаю всего что он делал, но видел попытки запуска 1С в командном режиме сразу с запуском Тестирования и исправления ИБ, которые собственно ничего не запускали.

Я заострил свое внимание на SQL. Небольшой опыт конфигурирования и администрирования баз и типовой набор sql-команд мне знаком, но изложенный ниже способ итак не потребует никаких глубоких знаний и навыков работы с SQL. Я просто подключил логику — если база «упала» в момент сохранения конфигурации, делаем вывод, что в SQL могла порушиться структура одной таблицы (хотя я не знал до этого что конфигурация в 8 версии лежит в одной сиквель таблице) и эта таблица в которой хранится конфигурация базы. а именном таблица dbo.config. Это в последствии я узнал методом «самотыка» и опять же логики, ибо единственное что нашел это местную разработку, мне не помогшую но довольно полезную на будущее, а именно http://infostart.ru/public/61114/ Спасибо автору от учетки моего коллеги, с помощью которого я ее скачал. Итак перехожу к самому важному — попытки(!) восстановления базы ибо гарантий никаких я вам, к сожалению, дать не могу и тому есть ряд предустановок, которых у вас может и не быть или как говорится — это не ваш случай…

Требования и непосредственно само восстановление базы

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

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

Исходные данные — SQL база 1С 8.2, конфигурация УПП 1.3.22.1 (полагаю описанный способ подойдет для любой эскюэльной базы 8.2). SQL сервер 2005. Ошибка описанная в анонсе и ошибка возникшая в момент сохранения конфигурации! Самое важное и обязательное требование!!! Копия SQL базы с ТАКОЙ  ЖЕ КОНФИГУРАЦИЕЙ(!) У нас настроен авто-обмен с другой базой и конфигурации их совпадают. Кроме этого, так как нас трое программистов 1С — у каждого есть выгруженный и относительно свежий файл конфы. По факту подойдет любая база, неважно с какими данными, главное чтобы конфигурация в ней соответствовала структуре метаданных базы. Отмечу тот факт, что конфигурация даже немного отличалась от той, с которой база вылетела. Самое основное, на мой взгляд, требование, чтобы отличия в конфигурации не затрагивали метаданные. Не стоит забывать тот факт, что если конфигурация отличается, то в итоге вы получите рабочую базу но с конфигурацией из вашей копии.

Сам процесс восстановления не займет у вас много времени — буквально пару минут, но крайне рекомендую предварительно сделать бэкап даже «упавшей» базы, а он может занять время. Например у вас будет возможность восстановить базу откатом из log-файла (который у нас к сожалению в суматохе восстановления «грохнули») или еще какой способ. Итак, напомню что где то должна быть SQL база неважно какими данными но с такой же конфигурацией. Если у вас конфигурация представляет из себя «нетроганную» типовую  (что подразумевает, что данная проблема возникла в процессе наката новой типовой конфигурации) — можете создать новую пустую базу и залить туда типовую конфу, которая у вас была до этого. В случае, если конфигурация, которую вы нашли, не такая уж свежая — подумайте и примите решение, возможно те отличия с копией конфигуратора, которые вы будете вынуждены повторить в вашей базе, займут много больше времени и ресурсов, нежели потеря информации самой базы данных 1С. Своеобразная палка о двух концах ) Итак…

1. Делаем бэкап рухнувшей базы средствами SQL.

2. Очищаем таблицу dbo.config нашей базы в которой лежит наша порушенная конфа. Это можно сделать из SQL- Profiler, к примеру запустив в нем команду:

Use Base2009

go

Delete From [DBO].[Config]

go

где Base2009 имя рухнувшей базы.

Примечание: где-то в сети читал непроверенную инфу, что иногда помогает очистка таблицы dbo.ConfigSave, в которой, якобы, лежит накатываемая конфа. В нашей базе она оказалась пустая, поэтому чистить пустую таблицу, понятно не стал. Возможно — можно как-нибудь обмануть и оживить базу 1С, используя данную таблицу но, не зная механизм работы 1С с этой таблицей, ничего не буду говорить в плане действий, применительно к ней.

3. Копируем таблицу из базы с целой конфигурацией, в нашу порушенную базу. В моём случае обе базы были на одном сервере поэтому команда копирования в SQL-Profiler выглядела так.

insert into [base2009].[Dbo].[Config] select * from [BaseCopy].[Dbo].[Config]

go

где base2009 — имя рухнувшей базы, BaseCopy имя базы с копией конфигуратора

4. Запускаем 1С, и в случае успеха — прыгаем, как я от радости, что удалось оживить базу без каких-либо потерь информации.

5. (Капитан очевидность) проверяем отлаживаем и следим за системой создания бэкапов базы и очень ответственно подходим к процессу обновления конфигурации (делаем это не по сети, а желательно на сервере, по возможности сделав предварительно бэкап). Особенно если версия вашей 1С стала 8.2. Насколько я понял из статей в сети и превых двух дней работы с ней, что она более чувствительна и капризна, по сравнению 8.1 с которой таких проблем не было.

5а. Если конфигурация базы с которой вы будете копировать таблицу конфы — все-таки отличается, (не имея при этом отличий в метаданных, о чем я уже говорил), и где-то лежит ваш относительно свежий cf-файл с выгруженной конфой — накатываем его на ожившую базу. В противном случае Вам придется повторить все те отличия, которые были с копией конфигуратора. Так что еще раз хорошо подумайте и проанализируйте — что важнее — ваша работа по изменению конфигурации (и сколько времени вы на это потратите) или работа пользователей базы до момента последнего бэкапа. В моем случае это была работа 2-х программистов в течении 3-х часов против работы порядка 100 пользователей в течении 1.5 дней, так что выбор был очевиден.

З.Ы. Еще раз напомню, что данная функция восстановления является недокументированным 1С-овцами способом восстановления базы (в конкретном случае обрушения базы, произошедшего в процессе сохранения конфы) и все что вы делаете — вы делаете на свой страх и риск, но конкретно в моем случае других путей оживить базу с минимальной потерей существующей информации не было (лог файл потерли и самый свежий бэкап представлял потерю 1.5 дня работы порядка 100 пользователей), поэтому, как говорится мосты были сожжены )

З.Ы.Ы. Это моя первая публикация тут т.к. трусь на других 1С форумах, но нахожу этот ресурс одним из самых полезных в плане выложенных разработок и публикаций, поэтому не судите строго за много ЕСЛИ в данной публикации). Буду очень рад, если реально помог кому-нибудь с восстановлением порушенной базы ибо страшнее этого только ядерная война )

З.Ы.Ы.Ы. Спустя 3 недели проблема повторилась ) На этот раз на решение было потрачены какие-то секунды (если не учитывать время создания бэкапа), и даже пользователей не пришлось выгонять.

_____________________________________________________________________________________________________________

Сегодня прибежал коллега. Та же самая беда. Только база тестовая а не рабочая и сама база ему поскольку постольку — а вот конфигуратор ему важен. Неделю он краптел над ним ни разу не выгрузив в cf файл и не накатив изменения в рабочую базу. Ну что ж — почему бы не поковырятся уже с таблицей?! На этот раз все еще проще. Открываю SQL Managment Studio. Формирую запрос по таблице на поля с текущей датой изменения и временем когда у него вылетела база — результат дает 2 записи. Первая — Поле FileName  = «commit» Ну что же — грохнуть эту запись — и у меня все получилось! Конфигуратор ожил и база опять работает. Что же нужно сделать?! 

Итак в открытом окне SQL Managment Studio ищем нашу базу — открываем Таблицы, ищем в конце списка таблицу с конфой dbo.config на таблице — правую кнопку — Открыть таблицу. Далее в правом окне спускаемся в самой таблице вниз по алфавиту на поле где FileName  = «commit». Встаем на эту запись — правую кнопку мыши — Удалить. В общем удаляем  запись с двоичным файлом. Далее пробуем зайти в конфу. Ошибка та же самая первая появляется. Наверно не получилось?Ё  Нажимаем Ок. И тут, прежде чем выдать как ранее 2-е сообщение о невозможности сохранить —  компьютер задумался. Спустя секунд 30 — О ЧУДО! Конфигуратор открылся. Пробуем сохранить конфигуратор (предварительно сохранив cf файл). Конфигуратор сохраняется. Таким образом и волки сыты и овцы целы. Не уверен насчет полной работоспосбности базы после таких измывательств — так что посоветую сделать реструтуризацию и пересчет итогов уже потом вечером (предварительно конечно же сделав архив). Удачного востановления и положительных эмоций )

Автор: Олег Ряднов