gifts2017

Восстановление SQL базы 1С 8.2. после неудачного сохранения конфигурации

Опубликовал Петр Суренков (lord_soth) в раздел Администрирование - Архивирование (backup)

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

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

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

 

См. также

PowerTools от 1 000
Подписаться Добавить вознаграждение
Комментарии
1. Дмитрий Бухалов (Re:аниматор) 19.07.13 05:41
А правда 2000 пользователей? просто у нас 1С:УТ 200 пользователей и БД 150 гб, при таком кол-ве пользователей БД была бы терабайты :-)
2. Петр Суренков (lord_soth) 19.07.13 06:55
(1) Re:аниматор, может наши лениивее ваших? У нас УПП и этой базе всего 2 года, плюс периодически чистятся логи, журнал регистрации и делается шринкование, на данный момент база занимает около 160Гб. А у Вас сколько лет базе?
3. dka80 ~ (dka80) 19.07.13 10:41
Спасибо за информацию. Однако замечу, что может вы плохо искали, но решения проблем с испорченными таблицами configsave имеются на просторах рунета. Причем они совпадают с вашим.
Gilev.Vyacheslav; +1 Ответить 1
4. al petrov (petrov_al) 19.07.13 11:00
Спасибо, за еще один вариант востановления, раньше пользовался другими способами...
5. Петр Суренков (lord_soth) 19.07.13 11:00
(3) dka80, не спорю, может искал не достаточно хорошо, но те которые нашел, были аналогичны решению приведенному в этой статье, т.е. не подходили для случая, когда испорченная база и база с хорошей конфой находятся в разных кластерах.
6. Дмитрий Бухалов (Re:аниматор) 19.07.13 14:08
7. Вячеслав Гилёв (Gilev.Vyacheslav) 20.07.13 20:24
http://www.gilev.ru/restoreib/ черт знает сколько этой статье лет, побоялись бы бога так боянить
8. artur rakhmatulin (нормальный такой) 20.07.13 22:08
(7) Gilev.Vyacheslav, теперь мне стыдно что я поставил плюс.
но в своё оправдание скажу, я пока не сталкивался с такими ситуациями и тьфутьфутьфу. Но я зашел на портал, увидел и прочел эту публикацию, и мне показалось это полезным и с более-менее подробным описанием, чего сейчас мало.
Безусловно, я как и многие начинающие или профессионалы своего дела, посещали и изучали Ваш ресурс, но по всей видимости стоит уделить ему больше внимания, что бы не попадать впросак.

Спасибо и Вам и Автору.
9. Ирли Бёрд (EarlyBird) 21.07.13 00:15
(7) Gilev.Vyacheslav,
черт знает сколько этой статье лет, побоялись бы бога так боянить
во-первых, не надо богохульствовать
во-вторых, твоя статья не помогает в описанной автором ситуации. От твоего опуса пользы - как от козла молока.
Вот что написано у тебя:
в стандартной документации описан следующая возможная причина:
При старте 1С:Предприятие проверяет наличие в информационной базе таблицы
1. Config
2. ConfigSave
3. Files
4. Params
5. _YearOffset
6. DBSchema
и в случае отсутствия какой-нибудь из них выдается сообщение «информационная база разрушена».
zqzq; lord_soth; +2 1 Ответить 1
10. Ирли Бёрд (EarlyBird) 21.07.13 00:18
в отличие от тебя, автор приводит конкретное, пошаговое описание действий для восстановления таблиц Config и 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С.
11. Ирли Бёрд (EarlyBird) 21.07.13 00:21
поэтому, если у меня возникнет аналогичнаяситуация, статья автора мне реально поможет
в отличие от твоей статьи
поэтому не гневи Бога, действительно
dour-dead; lord_soth; +2 Ответить
12. Евгений ' (WanGoff) 21.07.13 01:57
Как по мне, статья действительно может пригодиться людям, не сталкивавшимся с подобной проблемой, или таблицами SQL.
Пригодится, если случится подобное. Но, по-хорошему, ситуация рабочая, и если программист 1С не решит такую проблему без сторонней помощи - то ему незачОт.
13. Ирли Бёрд (EarlyBird) 21.07.13 02:43
(12) WanGoff,
ситуация рабочая, и если программист 1С не решит такую проблему без сторонней помощи - то ему незачОт.
Во-первых, это отнюдь не рабочая ситуация. Рабочая она только у тех, кто регулярно юзает динамическое обновление (видимо, по недостатку мозгов).
Кто поумнее, динамическим обновлением стараются не злоупотреблять.
Во-вторых, в крупных конторах обязанности программиста 1С и администратора баз данных - зачастую разделены, и программист 1С не имеет доступ к администрированию SQL-сервера. Поэтому без помощи админа, программист подобную проблему не сможет решить.
Давайте чуть поменьше пафоса и распальцовок, ок?
Статья безусловно полезная.
lord_soth; нормальный такой; +2 Ответить 1
14. Петр Суренков (lord_soth) 21.07.13 10:28
(12) WanGoff, в обязанности программиста 1С в крупных фирмах, не входит администрирование базы и уж тем более, у него нет доступа к серверам.
(7) Gilev.Vyacheslav, спасибо за ссылку, но что из приведенного в ней, должно было бы мне помочь? Правильный ответ - ничего.
15. Алексей Бочков (Aleksey.Bochkov) 21.07.13 11:43
(0) мне всегда помогал иной, менее болезненный способ - удалить 2 записи в таблице с конфигурацией:
DELETE FROM [dbo].[Config]
      WHERE FileName = 'commit' or FileName = 'dbStruFinal'
simich; MiroAlex1987; SirYozha; WanGoff; lord_soth; +5 Ответить
16. Вячеслав Гилёв (Gilev.Vyacheslav) 21.07.13 14:17
(9) EarlyBird, смотри пункт 7.7 ...
17. Вячеслав Гилёв (Gilev.Vyacheslav) 21.07.13 14:19
18. Евгений ' (WanGoff) 21.07.13 14:20
(13) Когда б я хотел сказать что-нибудь пафосное, я б назвал недоумками всех, кто пользуется динамическим обновлением, в том числе и автора. Как сделали Вы, например.
(13) (14) Действительно, доступа к серверам нет в крупных конторах. Но тогда и статью незачем выкладывать. Коллизия. Или выкладывать статью, но тогда она пригодится программистам 1С.
19. Петр Суренков (lord_soth) 21.07.13 16:14
(17) Gilev.Vyacheslav, в том-то и дело, что конфигурация даже не близка к типовой, так что 7.7 не подходит.

(18) WanGoff, статья пригодится, если база источник и база приемник, будут находится в разных кластерах на разных серверах, что я и отметил 2 раза. И да, Вы правы, она еще может пригодиться если программист впервые сталкивается с такой проблемой и нет времени, на ее детальное изучение. Если вдруг что-то падает, а администратор БД находится в отпуске, то сисадмины быстро дают доступ. :)
20. Вячеслав Гилёв (Gilev.Vyacheslav) 21.07.13 19:32
еще раз убеждаюсь, что разные люди из одних и тех же фактов умудряются сделать диаметрально противоположные выводы
ну если вы не видите связи между "СУТЬЮ" моей рекомендации и своей, хотите найти различие в количестве "запятых", продолжать дальше нет смысла
я не против что периодически велосипед изобретается заново, авторство "на хорошую идею" не может быть

но пройдет несколько лет, и вы сами столкнетесь с тем как прочитаете у очередного "изобретателя" написанное здесь, вся история развивается по кругу....
21. Петр Суренков (lord_soth) 21.07.13 19:48
история развивается по кругу...

(20) Gilev.Vyacheslav, вы правы и действительно, давайте дальше не продолжать.
22. Владислав Свинцов (VSvintsov) 21.07.13 20:32
хорошая статья, правда не хватает одного абзаца:
выяснив, что ночной архив становится неактуальным уже через пару часов - завели лог файл на БД MS SQL и в течении дня архивируем логи с интервалом в 20 мин :-)
Тогда максимум что теряется - это 20 или менее минут работы, и восстановление не занимает длительного времени.
23. Петр Суренков (lord_soth) 21.07.13 22:17
(22) VSvintsov, да сейчас решили на стример копию делать. :)
24. Александр Милютин (sanfoto) 22.07.13 06:36
Ранее использовал похожую схему востановления (средствами MS SQL) таблицы "Config///База_Рабочая" путем копирования из "Config///БазаПустышка".
При этом "БазаПустышка" - пустая база - просто подключенная к "Хранилищу конфигурации" -
- т.е. собственно перед копированием делал Обновление этой конфигурации из Хранилища .


НО начиная с релиза движка 8.2.17(проверял начиная с 8.2.17.169) - все это НЕ АКТУЛЬНО.... глюков больше нет!
25. Петр Суренков (lord_soth) 22.07.13 06:59
(24) sanfoto, у нас как раз был 8.2.16. :( Каким образом проверяли? Есть ли подтверждение от 1С?
26. Андрей Конев (Infector) 22.07.13 08:58
Еще немножко по теме - возможно просто совпадение, но заметили интересную штуку - если перед динамическим обновлением конфигурацию сохранить (Ctrl+s, только затем F7) вероятная проблема с базой проявляется менее жестко - можно успешно выгнать всех пользователей и обновить базу без колдовства в SQL
27. vicmos victor (vicmos) 22.07.13 10:09
Спасибо, решение простенько и со вкусом.
28. Сергей Гуков (SirYozha) 22.07.13 11:41
(24) тоже интересует, каким образом проверяли? )
29. Александр Милютин (sanfoto) 22.07.13 12:02
(25) lord_soth, (28) SirYozha,
у нас как раз был 8.2.16. :( Каким образом проверяли?


В работе проверяли как еще )) и да вроде как на официальном было написано что исправили ДеМоническое обновление в 8.2.17.
Несколько месяцев 8.2.17.169 - Динамические (уже не ДеМонические можно назвать) обновления (несколько прогеров) очень частые - глюков со слетом конфигурации нет вообще.

ЗЫ:
Напрямую в ЦЕНТРАЛЬНОЙ БАЗЕ ничего не пишем - ВСЕ через "Хранилище Конфигурации" , у каждого прогера своя БД.
30. Петр Суренков (lord_soth) 22.07.13 12:32
(29) sanfoto, спасибо, похоже решили эти проблемы с падением конфигурации, надо переходить на 8.2.17.
http://downloads.v8.1c.ru/content/Platform/8_2_17_128/ErrPlatform_8_2_17_128.htm
31. Андрей Конев (Infector) 22.07.13 12:55
8.2.17.ххх не панацея, падает, но только значительно реже. Поэтому не забываем делать Бэкапы перед тем как обновляться.
32. Александр Милютин (sanfoto) 22.07.13 13:08
(31) Infector,
Поэтому не забываем делать Бэкапы перед тем как обновляться.

зачем Полный БэкапКаждый раз? если падает только таблица конфигурации...
если уж предусматривать такую возможность то делаем как в (24) sanfoto, т.е. НЕПИШЕМ СРАЗУ в центральной а юазаем "Хранилище конфигурации" или пишем код в "Отдельной БД".

ПС:
Хотя бэкапы у нас Всетаки делаются))
1)Полный бакап раз в Сутки -
2)и Транзакшен-лог каждый час...есно все автоматом))

ПС2:
У нас программа работает 24/7 выхода нет - кроме динамического обновления - кого касается тот перезапустит программу(или мы сами "нуждающимся" поможем перезапустить))) ).
33. Андрей Конев (Infector) 22.07.13 13:19
По большому счету главное иметь в бэкапе конфигурацию до изменения, чтобы не так обидно было часть измененений терять при вероятном восстановлении. Если в ночном бэкапе все есть, он, конечно же, устраивает.
PS: до хранилища конфигурации пока не доросли.
34. diver.sun diver.sun (diver.sun) 22.07.13 15:15
Сталкивался с такой же ситуацией, когда проводил не динамическое а обычное обновление, и погас сервер HASP....обошел проблему следующим образом: Очистил таблицу configsave потом отсортировал таблицу config и посмотрел что изменялось последним, там был какая то запись признак.....название хоть убейте не вспомню.....он имел дату модификации большею чем записи данных.....и нулевой размер, я его удалил, и база вообще забыла что хотела обновится
35. Геннадий Зимин (kenza) 22.07.13 15:48
(33) Infector, согласен. Постоянно тестирую изменения конфигурации локально, потом уже заливаю новую. Старая конфигурация так же сохраняется. Динамическое обновление вообще больше никогда не использую, так как уже убедился, что это ни к чему хорошему не приводит )
36. Алексей Соловьев (Silenser) 23.07.13 11:45
На самом деле достаточно один раз написать скрипт, который бы бекапил 2 таблички с конфой в новые таблички внутри той же базы через select into. При его запуске перед обновлением косяк динамики решается за 1 минуту. Проще предупредить, чем лечить ;)
dr.death; +1 Ответить
37. andrey dyak (dyak84) 23.07.13 17:19
Автору спасибо за статтю как раз пригодилась. попробовал зделал все получилось правда пришлось немного подождать пока резервная база из DТ. раскрутится. Еще хотело бы поблагодарить автора коментария (10) за подробно и детальное описание процеса запуска 1С и какие таблици при етом используются. Так держать.
38. Петр Суренков (lord_soth) 23.07.13 17:28
(37) dyak84, так 10-й комментарий это, собственно, цитата из статьи. :)
39. Марина Чирина (chmv) 24.07.13 12:38
40. Oberonm (oberonm) 30.07.13 11:37
Глюк такой бывал частенько по причине того, что и SQL и сервер приложения были на одном сервере. стоило разнести на разные сервера, так сразу прекратились. А статья - баян. на инфостарте полно статей на эту тему подробных. сам ими пользовался
41. Michael Cher (mmch) 14.08.13 13:15
Не думал, что пригодиться, а сегодня пригодилось! Спасибо, Метод рабочий, проверено лично =)
42. Евгений (Evmil) 06.08.14 12:42
(31) Infector, если при динамическом обновлениии база вылетела, то потом выгоняем пользователей, продолжаем обновление монопольно и все ОК при платформе > 8.2.16.
43. ффф ыыы (zqzq) 25.07.16 09:15
Было на днях. Платформа 8.2.19.68. После динамического обновления перестала пускать и в конфигуратор, и в предприятие, при этом окно запуска и всё, никаких сообщений. Статья реально помогла, доступно и по делу пошаговая инструкция.
44. Петр Суренков (lord_soth) 26.07.16 17:33
(43) zqzq, рад, что статья пригодилась.