Поводом к написанию данной статьи, послужило падение базы во время сохранения конфигурации, при динамическом обновлении. Казалось бы сколько уже раз предупреждали — «Не делайте динамическое обновление на 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С и все действия, вы выполняете на свой страх и риск, а документированный способ — это восстановление из бэкапа.
Надеюсь эта статья, кому-нибудь поможет сэкономить время и нервы.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
А правда 2000 пользователей? просто у нас 1С:УТ 200 пользователей и БД 150 гб, при таком кол-ве пользователей БД была бы терабайты 🙂
(1) Re:аниматор, может наши лениивее ваших? У нас УПП и этой базе всего 2 года, плюс периодически чистятся логи, журнал регистрации и делается шринкование, на данный момент база занимает около 160Гб. А у Вас сколько лет базе?
Спасибо за информацию. Однако замечу, что может вы плохо искали, но решения проблем с испорченными таблицами configsave имеются на просторах рунета. Причем они совпадают с вашим.
Спасибо, за еще один вариант востановления, раньше пользовался другими способами…
(2) 4.5 года
черт знает сколько этой статье лет, побоялись бы бога так боянить
(7) Gilev.Vyacheslav, теперь мне стыдно что я поставил плюс.
но в своё оправдание скажу, я пока не сталкивался с такими ситуациями и тьфутьфутьфу. Но я зашел на портал, увидел и прочел эту публикацию, и мне показалось это полезным и с более-менее подробным описанием, чего сейчас мало.
Безусловно, я как и многие начинающие или профессионалы своего дела, посещали и изучали Ваш ресурс, но по всей видимости стоит уделить ему больше внимания, что бы не попадать впросак.
Спасибо и Вам и Автору.
(7) Gilev.Vyacheslav,
во-первых, не надо богохульствовать
во-вторых, твоя статья не помогает в описанной автором ситуации. От твоего опуса пользы — как от козла молока.
Вот что написано у тебя:
При старте 1С:Предприятие проверяет наличие в информационной базе таблицы
1. Config
2. ConfigSave
3. Files
4. Params
5. _YearOffset
6. DBSchema
и в случае отсутствия какой-нибудь из них выдается сообщение «информационная база разрушена».
в отличие от тебя, автор приводит конкретное, пошаговое описание действий для восстановления таблиц 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С.
Показать
поэтому, если у меня возникнет аналогичнаяситуация, статья автора мне реально поможет
в отличие от твоей статьи
поэтому не гневи Бога, действительно
Как по мне, статья действительно может пригодиться людям, не сталкивавшимся с подобной проблемой, или таблицами SQL.
Пригодится, если случится подобное. Но, по-хорошему, ситуация рабочая, и если программист 1С не решит такую проблему без сторонней помощи — то ему незачОт.
(12) WanGoff,
Во-первых, это отнюдь не рабочая ситуация. Рабочая она только у тех, кто регулярно юзает динамическое обновление (видимо, по недостатку мозгов).
Кто поумнее, динамическим обновлением стараются не злоупотреблять.
Во-вторых, в крупных конторах обязанности программиста 1С и администратора баз данных — зачастую разделены, и программист 1С не имеет доступ к администрированию SQL-сервера. Поэтому без помощи админа, программист подобную проблему не сможет решить.
Давайте чуть поменьше пафоса и распальцовок, ок?
Статья безусловно полезная.
(12) WanGoff, в обязанности программиста 1С в крупных фирмах, не входит администрирование базы и уж тем более, у него нет доступа к серверам.
(7) Gilev.Vyacheslav, спасибо за ссылку, но что из приведенного в ней, должно было бы мне помочь? Правильный ответ — ничего.
(0) мне всегда помогал иной, менее болезненный способ — удалить 2 записи в таблице с конфигурацией:
(9) EarlyBird, смотри пункт 7.7 …
(14) смотри пункт 7.7
(13) Когда б я хотел сказать что-нибудь пафосное, я б назвал недоумками всех, кто пользуется динамическим обновлением, в том числе и автора. Как сделали Вы, например.
(13) (14) Действительно, доступа к серверам нет в крупных конторах. Но тогда и статью незачем выкладывать. Коллизия. Или выкладывать статью, но тогда она пригодится программистам 1С.
(17) Gilev.Vyacheslav, в том-то и дело, что конфигурация даже не близка к типовой, так что 7.7 не подходит.
(18) WanGoff, статья пригодится, если база источник и база приемник, будут находится в разных кластерах на разных серверах, что я и отметил 2 раза. И да, Вы правы, она еще может пригодиться если программист впервые сталкивается с такой проблемой и нет времени, на ее детальное изучение. Если вдруг что-то падает, а администратор БД находится в отпуске, то сисадмины быстро дают доступ. 🙂
еще раз убеждаюсь, что разные люди из одних и тех же фактов умудряются сделать диаметрально противоположные выводы
ну если вы не видите связи между «СУТЬЮ» моей рекомендации и своей, хотите найти различие в количестве «запятых», продолжать дальше нет смысла
я не против что периодически велосипед изобретается заново, авторство «на хорошую идею» не может быть
но пройдет несколько лет, и вы сами столкнетесь с тем как прочитаете у очередного «изобретателя» написанное здесь, вся история развивается по кругу….
(20) Gilev.Vyacheslav, вы правы и действительно, давайте дальше не продолжать.
хорошая статья, правда не хватает одного абзаца:
выяснив, что ночной архив становится неактуальным уже через пару часов — завели лог файл на БД MS SQL и в течении дня архивируем логи с интервалом в 20 мин 🙂
Тогда максимум что теряется — это 20 или менее минут работы, и восстановление не занимает длительного времени.
(22) VSvintsov, да сейчас решили на стример копию делать. 🙂
Ранее использовал похожую схему востановления (средствами MS SQL) таблицы «Config///База_Рабочая» путем копирования из «Config///БазаПустышка».
При этом «БазаПустышка» — пустая база — просто подключенная к «Хранилищу конфигурации» —
— т.е. собственно перед копированием делал Обновление этой конфигурации из Хранилища .
НО начиная с релиза движка 8.2.17(проверял начиная с 8.2.17.169) — все это НЕ АКТУЛЬНО…. глюков больше нет!
(24) sanfoto, у нас как раз был 8.2.16. 🙁 Каким образом проверяли? Есть ли подтверждение от 1С?
Еще немножко по теме — возможно просто совпадение, но заметили интересную штуку — если перед динамическим обновлением конфигурацию сохранить (Ctrl+s, только затем F7) вероятная проблема с базой проявляется менее жестко — можно успешно выгнать всех пользователей и обновить базу без колдовства в SQL
Спасибо, решение простенько и со вкусом.
(24) тоже интересует, каким образом проверяли? )
(25) (28) SirYozha,
В работе проверяли как еще )) и да вроде как на официальном было написано что исправили ДеМоническое обновление в 8.2.17.
Несколько месяцев 8.2.17.169 — Динамические (уже не ДеМонические можно назвать) обновления (несколько прогеров) очень частые — глюков со слетом конфигурации нет вообще.
ЗЫ:
Напрямую в ЦЕНТРАЛЬНОЙ БАЗЕ ничего не пишем — ВСЕ через «Хранилище Конфигурации» , у каждого прогера своя БД.
(29) sanfoto, спасибо, похоже решили эти проблемы с падением конфигурации, надо переходить на 8.2.17.
8.2.17.ххх не панацея, падает, но только значительно реже. Поэтому не забываем делать Бэкапы перед тем как обновляться.
(31) Infector,
зачем Полный БэкапКаждый раз? если падает только таблица конфигурации…
если уж предусматривать такую возможность то делаем как в (24) sanfoto, т.е. НЕПИШЕМ СРАЗУ в центральной а юазаем «Хранилище конфигурации» или пишем код в «Отдельной БД».
ПС:
Хотя бэкапы у нас Всетаки делаются))
1)Полный бакап раз в Сутки —
2)и Транзакшен-лог каждый час…есно все автоматом))
ПС2:
У нас программа работает 24/7 выхода нет — кроме динамического обновления — кого касается тот перезапустит программу(или мы сами «нуждающимся» поможем перезапустить))) ).
По большому счету главное иметь в бэкапе конфигурацию до изменения, чтобы не так обидно было часть измененений терять при вероятном восстановлении. Если в ночном бэкапе все есть, он, конечно же, устраивает.
PS: до хранилища конфигурации пока не доросли.
Сталкивался с такой же ситуацией, когда проводил не динамическое а обычное обновление, и погас сервер HASP….обошел проблему следующим образом: Очистил таблицу configsave потом отсортировал таблицу config и посмотрел что изменялось последним, там был какая то запись признак…..название хоть убейте не вспомню…..он имел дату модификации большею чем записи данных…..и нулевой размер, я его удалил, и база вообще забыла что хотела обновится
(33) Infector, согласен. Постоянно тестирую изменения конфигурации локально, потом уже заливаю новую. Старая конфигурация так же сохраняется. Динамическое обновление вообще больше никогда не использую, так как уже убедился, что это ни к чему хорошему не приводит )
На самом деле достаточно один раз написать скрипт, который бы бекапил 2 таблички с конфой в новые таблички внутри той же базы через select into. При его запуске перед обновлением косяк динамики решается за 1 минуту. Проще предупредить, чем лечить 😉
Автору спасибо за статтю как раз пригодилась. попробовал зделал все получилось правда пришлось немного подождать пока резервная база из DТ. раскрутится. Еще хотело бы поблагодарить автора коментария (10) за подробно и детальное описание процеса запуска 1С и какие таблици при етом используются. Так держать.
(37) dyak84, так 10-й комментарий это, собственно, цитата из статьи. 🙂
Спасибо автору
Глюк такой бывал частенько по причине того, что и SQL и сервер приложения были на одном сервере. стоило разнести на разные сервера, так сразу прекратились. А статья — баян. на инфостарте полно статей на эту тему подробных. сам ими пользовался
Не думал, что пригодиться, а сегодня пригодилось! Спасибо, Метод рабочий, проверено лично =)
(31) Infector, если при динамическом обновлениии база вылетела, то потом выгоняем пользователей, продолжаем обновление монопольно и все ОК при платформе > 8.2.16.
Было на днях. Платформа 8.2.19.68. После динамического обновления перестала пускать и в конфигуратор, и в предприятие, при этом окно запуска и всё, никаких сообщений. Статья реально помогла, доступно и по делу пошаговая инструкция.
(43) zqzq, рад, что статья пригодилась.