gifts2017

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

Опубликовал Олег Ряднов (VanDiesel1) в раздел Администрирование - Архивирование (backup)

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

Предистория.

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

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

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

http://www.forum.mista.ru/topic.php?id=534298

http://devtrainingforum.v8.1c.ru/forum/thread.jsp?id=573910

http://sysadmins.ru/post9322239.html

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

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

См. также

Вознаграждение за ответ
Сумма: 0 $m
Добавили:
Владимир Баданов (ghostaz) (1.00 $m)
Подписаться Добавить вознаграждение

Комментарии

2. Олег Ряднов (VanDiesel1) 09.02.12 08:10
German, спасибо полезная ссылка!
3. Taras Варварич (itar59) 09.02.12 12:02
"... И опыт, сын ошибок трудных..."
прекрасное обобщение практики, и очень понятно.
СПАСИБО!
4. Вадим Matvienko (1cvirus) 09.02.12 12:46
чиню подобным скриптом
GO
DROP TABLE [ПОЛОМАНАЯ_БАЗА].[dbo].[Config]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [ПОЛОМАНАЯ_БАЗА].[dbo].[Config](
[FileName] [nvarchar](128) NOT NULL,
[Creation] [datetime] NOT NULL,
[Modified] [datetime] NOT NULL,
[Attributes] [smallint] NOT NULL,
[DataSize] [int] NOT NULL,
[BinaryData] [image] NOT NULL,
PRIMARY KEY CLUSTERED
(
[FileName] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
INSERT INTO [ПОЛОМАНАЯ_БАЗА].[dbo].[Config]
SELECT * FROM [БЭКАПНАЯ_БАЗА].[dbo].[Config]
GO
Andre32; s.matyukin_visma; partner1c; cj512; DrSender; trickster; dutlovva; dour-dead; Jkey; Nicholas; Aragorn; Release; pauchok; AlexGS; Kaavan; VitaliyTokarev; sakustov; ctulhua; Garstag; prokopulka; arabesca; ZeusF1; JohnyDeath; dandrontiy; skil; VanDiesel1; ГМВ; marsohod; +28 Ответить 7
5. napan Noname (napan) 14.02.12 09:01
Спасибо большое!
Я все таки надеюсь никогда не пригодиться.
Хотя всякое бывает, если что буду держать под рукой.
Сенкс!
6. Сергей Писларь (serpisal) 14.02.12 12:01
Согласен, хорошее решение, но никому не пожелаю причину, по которой ею можно воспользоваться, спасибо!
7. asady sad (asady) 14.02.12 15:59
Совсем недавно абсолютно похожая ситуация случилась и у меня

УПП 1.3.19 PostgreSQL 8.3.8
при обновлении конфигурации БД упал сеанс конфигуратора.
После этого случился сабж.
Очень помогла эта статья - но сделал немного по другому

через PG_ADMIN
1. copy config to '/home/user/config_1.txt в упавшей базе
2. copy config to '/home/user/config_0.txt в базе поднятой из последнего бэкапа
3. delete from config в упавшей базе
4. copy config from '/home/user/config_0.txt в упавшей базе

базу удалось восстановить без потерь информации
Повезло в том что при злополучном обновлении конфигурации менялась только прикладная логика
dour-dead; VanDiesel1; ГМВ; +3 Ответить 1
8. Наталия Ткаченко (natnat3) 15.02.12 09:33
кто предупрежден, тот вооружен.
9. Ruslan (rus128) 15.02.12 15:57
Спасибо!
Надеюсь - никогда не понадобится.
Замечания только по пунктуации.
10. Константин Матвеев (koka) 15.02.12 17:38
Спасибо за статью! Теперь можно более спокойно прыгать с парашютом (обновлять конфу, имея какоё-либо БЭКАП), имея ещё и запасной парашют (эту методику).
11. Sidor Petrov (1cinfo1) 16.02.12 05:39
(4) 1cvirus, Если не сложно, объясните, в чем заключается работа данного скрипта?
12. Евгений Горячев (art_m) 16.02.12 13:42
Спасибо большое за статью. Только что произошла такая же ситуация, никогда б не подумал, что при замене пары отчетов может такое случится....
13. Ярослав Новосёлов (novosys) 16.02.12 13:43
Для читателей: если у Вас не та самая критическая ситуация, описанная в статье, то рекомендую первым делом прочитать пункт 5! В нём наиболее важная информация, которая может помочь Вам избежать опыта автора.
А в целом - респект!
14. sound sound (sound) 16.02.12 15:41
Нормально, только мне кажется вместо

Delete From [DBO].[Config]


быстрей будет

TRUNCATE TABLE [DBO].[Config]
dutlovva; PavleG29; +2 Ответить 1
15. Анастасия Гальченко (katun) 17.02.12 18:09
Спасибо за статью! Возьму на вооружение! Ведь всякое бывает.
16. Вадим Matvienko (1cvirus) 22.02.12 15:51
(11) 1cinfo1,
удаляем таблицу конфигурации и записываем на ее место таблицу с рабочей конфигурацией
17. Олег Ряднов (VanDiesel1) 27.02.12 16:07
(16)Совершенно верно, если на пальцах - вычищаем таблицу с конфигурацией в рухнувшей базе и записываем туда такую же но рабочую конфигурацию из другой неважно какой базы...
Можно склеить пункт 2 и 3, предварительно убедивщись что таблица ConfigSave - пустая...
Use Base2009
go
Delete From [DBO].[Config]
go
insert into [base2009].[Dbo].[Config] select * from [BaseCopy].[Dbo].[Config]
go

(14) Возможно побыстрее будет - но в общей сложности пункт 2 + 3, на конфе УПП котоая весит в cf-файле 365 мб занял около 10 секунд, что для меня не очень критично.
18. Vova Nag (gely) 14.03.12 15:50
Спасибо огромное, действительно помогает и притом очень быстро.
19. Равиль (vip76) 15.03.12 01:48
Только что статья помогла, а думал что уже пушной зверек пришел....
20. Island-ua (StreamLVM) 16.03.12 05:27
Спасибо! Восстановил базу! Правда потерял пару дней своей работы, но это мелочи.
21. x50 03.04.12 13:35
Платформа 1С:Предприятие 8.2 (8.2.15.294).

При обновлении конфигурации конфигуратор завис, windows сказал что приложение будет закрыто. После этого в базу попасть никак не мог.
Пытался восстановить по инструкции http://www.gilev.ru/1c/81/restore/, но ситуация не изменилась.
Так как это была копия рабочей БД решил поэкспериментировать.
Сравнил чем отличаются таблицы Config битой базы от целой. В битой базе были 2 записи, которых небыло в целой, с полями FileName = 'commit' и FileName = 'dbStruFinal' binaryData 0x0. Никакой информации об этих полях не нашел. Удалил эти записи. Запустил конфигуратор, он выдал предупреждение "Внимание!!! При обновлении данных, после последней реструктуризации, произошла критическая ошибка. Повторить обновление?" нажал "Да" и все обновилось.
Не знаю на что еще могло повлиять удаление.
Olvia; hulio; +2 Ответить
22. DeD MustDie (DeD MustDie) 09.04.12 12:02
Спасибо большое за статью. Сегодня она меня реально выручила.
23. Серж Иванов (adminfo2002) 13.04.12 18:47
Полезная ссылка, спасибо. Один раз было, что сервер 1С обрубил соединение в момент сохранения конфигурации. В итоге в скуле получил "невосстановимая ошибка БД".

Знал бы раньше этот прикуп - жил бы в Сочи :)
24. Олег Ряднов (VanDiesel1) 18.04.12 14:45
Рекомендую при подобной ситуации попробывать восстановить базу исходя из последнего опыта и сноски. Все просто и быстро. Не нужны копии и скрипты. Правда как и в первом случае 100% успешного результата не обещаю но попробывать конечно же стоит...
25. Вадим Хасанов (vaZum) 19.04.12 09:32
Спасибо! Помогло. Аж руки трясутся до сих пор...
26. Vova Nag (gely) 20.04.12 10:40
Спасибо огромное за публикацию. Воспользовался ей повторно и особенно сноской. очень помогло, действительно описанным способом можно легко восстановить базу и хотя бы сделать бекап.
27. Andrey Dyak (electronik) 20.04.12 15:53
Спасибо огромное статья помогла. Но біло так страшно что передать не могу на все решилось автору огромное спасибо так дердать.Заслуженое 5+ респект
28. Дмитрий Павлюков (IT_PROGRAMMIST) 22.04.12 21:53
Хорошая статья.До этого была та же проблема. Думал смерть моя пришла).Выручила копия базы. Зато, после этой проблемы слежу за снятием копии ежедневно)))
29. Just (Just) 25.04.12 03:33
Автор написал, что на 81 таких проблемм не было, но мне кажется что было, да еще как. Происходили подобные сбои в случае неоднократного динамического обновления, без выгонялки пользователей. После одного из таких сбоев, была забавная ситуация, пускало в конфигуратор и в предприятие одного-двух пользовтаелей, если больше базы висла "наглухо", ни выгрузку ни ТИИ не отрабатовало, приводило к зависанию. Приведенным в статье способом, базу поднять не удалось, к счастью потерялось с прошлого бэкапа 2-3 часа. С тех пор больше никогда не использую динамическое обновление больше 1-го раза в день, даже по-мелочи. Честно говоря надеялся, что эти проблеммы ушли в 82, но видать нет. Еще удивляет, когда я искал подобную проблемму пару лет назад на форумах, то такой ситуацией сталкивались единицы, а в коментах у этой стать чуть ли не каждый второй пишет о подобной проблемме, лично у меня за крайние 2 года больше не было таких косяков, к счаcтью.
30. Денис Клюшин (denklu) 05.05.12 14:20
Спасибо Огромное!!!. все аналогично как и у других: было очень страшно и руки до сих пор трясутся, плюс я завтра в опуск, поэтому было вдвойне страшно.
копия есть ночная, но она меня не сильно бы спасла, как раз сегодня менеджеры решили перебить кучу доков и в 10 рук непрерывно с сомого утра стучат по клавишам.

все больше никаких динамических

восстановил по вышеописанному скрипту:

Use Base2009
go
Delete From [DBO].[Config]
go
insert into [base2009].[Dbo].[Config] select * from [BaseCopy].[Dbo].[Config]
go
dutlovva; Istur; +2 Ответить
31. Kirill Petrov (ZeusF1) 11.05.12 17:33
(4) 1cvirus, Спасибо, думал сам писать потом увидел комментарий.

Вернул таблицу из копии, все заработало.
32. Dima K (H0SE) 12.05.12 00:00
Была практически такая ситуация. Помог вовремя сделанный бэкап до обновления. Бэкап рулит )). Спасибо за статью. Теперь буду еще более готов ко всяким таким вещам.
33. mxm2 mxm2 (mxm2) 17.05.12 15:09
Спасибо огромное! Реально спасло. Работает на MS SQL 2008 R2 64x. Данные сохранились все; единственно во время первого запуска конфигуратора в заголовке появился <!> (несмотря на то что предварительно была очищена ConfigSave). ну и сохранение конфигурации происходило очень долго ~ 5 минут. Вобщем, все по делу - спасибо.
34. mxm2 mxm2 (mxm2) 17.05.12 15:14
(29) Just, 3 года обновлял динамически на 8.1 - не было проблем ни разу... а на 8.2 - за год - 2 раза падала, один раз успешно восстанавливал как описано в статье... да вобщем-то 8.3 готовится... )))
35. Сергей Любавин (SteelWalk) 01.06.12 09:15
Use Base2009
go
Delete From [DBO].[Config]
go
insert into [base2009].[Dbo].[Config] select * from [BaseCopy].[Dbo].[Config]
go

Шедевриальный скрипт!!!

Шикарно просто, ОГРОМНЕЙШЕЕ СПАСИБО за идею, до сих пор шок, как ваще такое может случиться....добавил в оборотно-сальдовую ведомость номера страниц блин........
36. Андрей Матвеев (shatur) 12.06.12 13:56
Есть новое решение проблемы, для тех у кого не сохранилось базы с такой же конфигурацией;
1. Очищаем configsave
2. delete from config where FileName = 'commit'
3. delete from config where FileName = ' dbStruFinal'.
Запускаю 1С, все работает. Потом попробовал сохранить конфигурацию, все сохранилось, работаем уже на такой базе в течении 5-ти часов, полет нормальный, вариант кстати очень быстрый
37. Алексей Скородумов (kartoshka) 16.06.12 20:39
Спасибо! Мне статья очень помогла
38. Денис Андриянов (arabesca) 21.06.12 11:03
(4) 1cvirus, о, спасибо... помогло!
39. Nadezhda N (prokopulka) 21.06.12 11:05
(4) 1cvirus, прямо жизнь спасло! Спасибо!
40. Илья Глебов (IlyaGlebov) 22.06.12 10:11
Спасибо большое за статью, взял конфигу из центрального узла (отличающуюся но без изменения в метаданных), создал пустую базу, загрузил. Запустил код - все заработало!
41. Ловыгин Антон (wunderland) 22.06.12 10:27
и отдельное спасибо за "Я ухожуй" :))
RibD; dutlovva; Скорпио_шка; nzass; deadmz; +5 Ответить
42. Вася Гнобин (testmode) 22.06.12 12:58
Для себя завел правило перед любым обновлением конфы сначала Бакап, имхо ведь можно так запороть базу что и простое перезаливание конфы из другой базы не поможет.
43. Ловыгин Антон (wunderland) 22.06.12 13:50
можно тогда написать процедуру/функцию которая будет конектится к своей SQL-базе и делать что-нить типа

insert into [Dbo].[Config]<Дата><Время> select * from [Dbo].[Config]

типа быстрый бекап cf-ника, ну а дальше мысль развивайте кто как хочет: можно на кнопку прикрутить к админскому интерфейсу, или программно определять, что это первый запуск(удачный) после пересборки(правда не знаю как, но мысль мне нравится). База при этом будет пухнуть и ее придется чистить переодически, но это уже другая история и всего лишь накладные расходы... Можно например создать под эти таблицы отдельный data-файл или вообще отдельную базу, не 1С-ную, под эти нужды(выдыхай борёр, выдыхай...)
Кому мысль нравится - ставим "+" коментарию не стесняясь.
VanDiesel1; +1 Ответить
44. Виктор Бизин (Bizzz) 26.06.12 15:15
Автору спасибо! Статья оказалась своевременной.
Опишу свой случай. Конфигурация: ЗУП 2.5.51.1. Размер базы 16 Гб.
На днях произошла ситуация - делал динамическое обновление. Спустя 2 дня 2 сотрудника пожаловались,
что при формировании расчетных листков программа вылетает с сохранением дампа. Причем на других компьютерах под их учетками этого не происходило. Остальные пользователи не жаловались.
Пытался имитировать на своем компьютере. Парадоксов было куча.
В рабочей базе все работало. В текущей (получасовой) копии - вылетала.
При исправлении и тестировании базы конфигуратор закрывался.
Пришел к выводу, что при сохранении в базу любых изменений в структуре конфигурации конфигуратор закрывался.
С копиями баз проблем не было - были за каждый день.
Перепробовав все способы наткнулся на эту статью.
Но... перенос таблицы dbo.Config не дал результата, зато показал куда копать.
Спасло перенос 3-х таблиц: Config, DBSchema, Params
http://www.forum.mista.ru/topic.php?id=557213&page=1
Так что автору rs_trade так же огромное спасибо!
45. Тимур Губайдуллин (timurti) 02.07.12 09:04
Спасибо большое,очень помогло!!!!
46. Oleg Kotysh (KotyshO) 04.07.12 08:48
Сегодня статья реально спасла, база умерла при обновлении - сделали все по инструкции - ожила как спящая красавица, так что спасибо человеку за его первую статью, дай бог не последнюю.
VanDiesel1; +1 Ответить
47. d3 r3 (ctulhua) 06.07.12 18:28
(4) 1cvirus, Отличный скрипт! Бекапы для трусов)))
48. Julia Galkina (lambert@inbox.ru) 09.07.12 21:52
ОГРОМНОЕ СПАСИБО!!!!!!!!!!!!!!!!!!!!!!!! Второй раз, благодаря Вашей статье, поднтмаем базу :)
49. Ксения (LadyDy) 16.07.12 13:50
(4) 1cvirus, подскажите пжл, что должно стоять вместо [ПОЛОМАНАЯ_БАЗА], я в скриптах плохо разбираюсь, а восстановить очень-очень надо. спасибо
50. Ксения (LadyDy) 16.07.12 14:51
(17) VanDiesel1, Подскажите пжл, можно ли восстановить не sql-ную базу
51. Ксения (LadyDy) 17.07.12 15:34
Ребята, подскажите, базу я восстановила через HxD, убрала из таблицы confif "commit". Только сейчас другая проблема. Конфа базовая, загружает обновление, начинает обновлять но обновление не заканчивает. Загружает конфигурацию и выкидывает служебное окно, что для обновления все готово, обновить или при следующей загрузке. И так бесконца. Пробовала обновить вручную, через конифигуратор выдает ошибку Неправильный путь к файлу 'v8srvr://dbeng8/f05133110/Config. Пробовала реструктуризацию, после этого ошибка формата потока и база перестает загружаться.
Помогите пжл, уже голову сломала.
52. Sova132 (Sova132) 26.07.12 15:35
нет слов моей благодарности! Тысячу раз спасибо. как вовремя я нашла вашу публикацию.
53. Денис Лазарев (irreal) 02.08.12 17:54
На терминалке кончилась память в момент динамического обновления. И дальше все по симптомам...
Догадывался, что так можно сделать, но без подтвержденного опыта не рискнул бы. А так юзеры курили около часа, пока тестовая копия жрала хранилице для создания нового прототипа config.
Большое спасибо!

И, нафиг-нафиг, поставлю ночное задание:

use my_1c_database_name
declare @name varchar(64)
select @name = name from sys.Tables where name = 'config_backup'
if @name = 'config_backup'
drop table config_backup
select * into config_backup from config
54. Евгений Фербер (omut) 03.08.12 13:30
Вот спасибо огромное! 5 минут и все готово. Учетом поиска этой статьи :) Бэкп был, но база тестовая и хотелось попытаться восстановить результаты до последнего изменения в течении дня хотя бы. В результате выяснилось, что сохранен уже самый последний вариант.
И еще небольшое наблюдения по подобным проблемам: лучше не сохранять сразу и рабочую конфигурацию, и конфу базы данных. Т.е. лучше сначала сохранить основную конфигурацию. А уже только после этого конфигурацию БД. Так ошибки появляются на порядок реже (если вообще появляются).
55. Татьяна Шешикова (shekl) 08.08.12 15:03
спасибо автору!!! База умерла при обновлении и отказывалась возрождаться, уже готовились к худшему (восстановление из бекапа с потерей данных за полдня), а тут ваша статья очень вовремя нашлась и жизнь наладилась ))). СПАСИБО!!!
56. Александр Шишигин (Alexsh_kz) 21.08.12 00:44
Олег, огромное тебе спасибо!
Выручил, уже не знал что делать с базой, вылетела в конце рабочего дня, а бэкап делается ночью, целый рабочий день 170 пользователей мог потеряться, меня бы расстреляли.. ))
Твой пост, реально помог.
57. Имя Фамилия (Mikons) 21.08.12 16:55
Мда, спасибо огромное за инфо. Случилась такая же проблема при динамическом обновлении периферийной БД, включающем незначительные изменения прав на объекты конфигурации.
После возникновения ошибки заметил зависшее несколько дней назад фоновое задание. думаю связано именно с этим. Так что перед обновлением убедитесь в отсутствие оных и включайте блокировку регламентных заданий.
58. KV1s (KroVladS) 21.08.12 17:12
В копилку.
Надеюсь никогда не придёться воспользваться.
59. Алена Алешина (марокко) 03.09.12 13:25
Спасибо огромное!!! Заработала база !
Ссылка на подобную тему только с использованием Microsoft SQL Server Menegement Studio
http://skyraven.ru/2012/08/16/ms-sql-restore/
60. irbek (irbek) 07.09.12 13:24
Огромное Спасибо! выручил
VanDiesel1; +1 Ответить
61. roman kalynchuk (romak78) 07.09.12 14:07
Мне в такой ситуации помогло:
1. Очищаем configsave
2. delete from config where FileName = 'commit'
3. delete from config where FileName = ' dbStruFinal'
Alta_k; dutlovva; dour-dead; Aragorn; mordiros; STivO; 4rtehouse; VanDiesel1; +8 Ответить 1
62. наташа (pattyx) 13.09.12 15:34
Спасибо, сегодня восстановила таким образом базу.

Уйма времени ушла на создание бекапа. Минут 5 выполнялся запрос:
Use Base2009
go
Delete From [DBO].[Config]
go
insert into [base2009].[Dbo].[Config] select * from [BaseCopy].[Dbo].[Config]
go

Теперь работает! :)
VanDiesel1; +1 Ответить
63. Карина -- (ponaroshku) 21.09.12 07:23
я вас люблю :))))

спасибо :)

Очень-очень-очень помогла ваша статья, восстанавливали тестовую базу, конфигурацию, вылетела при обновлении и возникла описанная в статье ошибка, но благодаря вашей статье все хорошо

Тысяча спасибо :)
VanDiesel1; +1 Ответить
64. Dragon Ago (DragonAgo) 21.09.12 08:25
Полезная статья, но лучше все-таки с таким встречаться редко, но про запас сохраню в книгу знаний
VanDiesel1; +1 Ответить
65. Олег Ряднов (VanDiesel1) 21.09.12 08:53
Рад что кому-то помог еще. Да и самому себе опять на днях пришлось помочь ) Переехали в новый офис а тут связь плохая с сервером. Ну и при сохранении конфы рухнула база опять. Восстановил минут за 15 без бэкапа - минут 12 ушло на то чтобы пользователей оставшихся выгнать
66. Алексей 1 (all_i_ance) 21.09.12 09:37
На такое дело, уважаемые товарищи! Нужно бэкапы хорошенько настроить :) И порсто напросто восстанавливать базу к рабочему состоянию :)

А если быть совсем добрым, то советую заглянуть http://www.sql.ru/forum/actualthread.aspx?tid=970460&hl=%e2%ee%f1%f1%f2%e0%ed%ee%e2%eb%e5%ed%e8%e5%20%­e1%e0%e7%fb

http://technet.microsoft.com/ru-ru/library/ms187048.aspx
plevakin; +1 Ответить
67. Дмитрий Гомзин (plevakin) 21.09.12 09:43
Уважаемый, спасибо конечно за информацию о сайте sql.ru))))) Но мне кажется еще нужно по этой ссылочке прыгнуть http://www.sql.ru/forum/actualthread.aspx?tid=967520&hl=%e2%ee%f1%f1%f2%e0%ed%ee%e2%eb%e5%ed%e8%e5%20%­e1%e0%e7%fb

А вообще молодец, толково ты все обьяснил))) 5 с плюсом))))))))))))))
all_i_ance; +1 Ответить 1
68. Алексей 1 (all_i_ance) 21.09.12 09:44
(67) plevakin, Это все хорошо)))) Быстро ответил и все дела))) Но есть кнопка "Ответить" )))
69. Докторъ (den_bo) 21.09.12 21:13
Спасибо за статью, пригодилось, когда база после очередного демонического обновления перестала запускаться (зависала намертво при запуске)
70. Наталия Гаспарян (natali_gasparian) 27.09.12 15:37
71. Roman R (romann) 03.10.12 13:46
Респектище!
Просто спасли жизнь! )
72. Maxim k (maxis33) 04.10.12 17:00
Спасибо автору! Сегодня помогло!
73. Вадим Янчук (vadimlp77) 09.10.12 13:56
Помогло !!! Спасибо, хлопцы !
С самого утра страдаю.
74. artmicro (artmicro) 10.10.12 16:30
Спасибо огромное! Вот только что закончил востанавливать рабочую базу таким же способом. Правда бекапа не было. Пришлось собирать из хранилища.

Так что Ваша статья просто спасла жизнь :)
75. Евгений (Voody) 17.10.12 12:45
Статья спасла.. Спасибо!
76. Роман (Raminus) 17.10.12 13:11
Хорошая статья, плюсик однозначно!
77. Владимир Баданов (ghostaz) 28.11.12 16:27
Спасибо огромное! Только что восстановил базу после неудачного обновления.
78. Александр Гончаров (aegoncharov) 28.11.12 18:45
Платформа 8.2.17.143

Исправлена ошибка:

10113064 Обновление конфигурации базы данных
Проблема:
Если процесс принятия изменений после обновления конфигурации базы данных был прерван, то на данную информационную базу может быть невозможно запустить ни в Предприятии, ни в Конфигураторе с различными сообщениями об ошибках или с аварийным завершением работы клиентского приложения или процессов сервера Предприятия.
Дата публикации:
2012-09-20

Это её наконец поправили?
79. Erdos Temirzhanov (erdos) 28.11.12 23:30
используй Тестирование и Исправление базы данных
80. Анаит Бадалян (LaNaite) 12.12.12 16:55
Спасибо за статью! Сегодня она реанимировала базу!
81. Родион (lamdth) 21.12.12 16:26
(79) erdos, при тестировании конфигуратор вылетает
82. Dmitriy Radovskiy (myoff) 27.12.12 14:09
Вообще в configsave хранятся только измененные объекты, не вся конфигурация.
При обновлении конфигурации записи из configsave копируются в config замещая аналогичные записи, потом таблица configsave очищается, а в таблице config записи где FileName = 'commit' и FileName = 'dynamicCommit' удаляются.

Мне в такой же ситуации когда во время сохранения конфигурации произошел сбой помогло:
1. В моем случае таблица configsave была пустая, если бы была полная - надо было очистить.
2. delete from config where FileName = 'commit'
3. delete from config where FileName = 'dynamicCommit'

P.S.
Другие записи, в том числе, где FileName = 'root', FileName = 'DynamicallyUpdated', FileName = ' version', FileName = 'versions' трогать не надо.
Можно удалить запись где FileName = 'dbStruFinal', но она в принципе не влияет на загрузку, удалится сама при очередном обновлении.
Alta_k; Nicholas; Aragorn; veforg; taishy; mordiros; +6 Ответить
83. Vitaliy Tokarev (VitaliyTokarev) 11.01.13 17:39
(4) 1cvirus, Спасибо! Хирургически восстановил БД. Помогло!
VanDiesel1; +1 Ответить
84. Вадим Назаров (NazarovV) 17.01.13 12:48
Читал с месяц назад эту статью, сегодня пригодилось!!! Спасибо! Нам помогло!
Во время динамического обновления вылезла такая же ошибка на 1С:УПП 8.2; MS SQL 2008;
восстановили другую конфигурацию по данному методу, кстати она тоже была изменена...Взлетело!
VanDiesel1; +1 Ответить
85. Константин (maverick76) 12.02.13 22:08
Статья хорошая. Предупреждён значит вооружён!
VanDiesel1; +1 Ответить
86. Елена Смирнова (Nefrit88) 01.04.13 06:35
Доброго времени суток! Попробовали реализовать сие на своей "горе базе". Зашли в таблицу config и грохнули запись commit. После этих приседаний предприятие работает, а вот в конфигуратор входить отказывается! Думает и в итоге выдает "Перезапустить конфигуратор?" Жмешь "нет", просто закрывается, жмешь "да" все тоже самое! Ждем обеда, будем полностью очищать таблицу.....оооочень надеемся что поможет. Если у кого была подобная проблема, прошу откликнуться
87. Елена Смирнова (Nefrit88) 01.04.13 10:15
метод
INSERT INTO [ПОЛОМАНАЯ_БАЗА].[dbo].[Config]
SELECT * FROM [БЭКАПНАЯ_БАЗА].[dbo].[Config]

помог! ликуем! спасибо создателю статьи!
VanDiesel1; +1 Ответить
88. Александр Мордирос (mordiros) 14.04.13 19:40
(61) romak78,
Спасибо, помогло.
Согласен с Вами. В корректно обновленной конфигурации базы данных (таблица Config) таких строк быть не должно.
Пустая таблица ConfigSave означает, что она основная конфигурация не отличается от конфигурации базы данных.
VanDiesel1; +1 Ответить
89. Степан Запорный (zastep) 15.04.13 10:54
Хорошая статья! Всё просто и понятно.
Огромное Спасибо Автору!
ООООЧЧЧЕНЬ пригодилось!
VanDiesel1; +1 Ответить
90. Дмитрий Глеков (glek) 26.06.13 16:11
Только что пригодилось. Несмотря на то, что бэкап двухдневной давности был - БОЛЬШОЕ СПАСИБО!!!!
VanDiesel1; +1 Ответить
91. Алексей (AlexGS) 16.08.13 14:00
5+ Ложу в копилку. Надеюсь не пригодится... )))
92. Михаил Проходцев (PoZiTiFFF) 07.10.13 09:09
(36) shatur, Уууууух помогло, спасибо.
93. Виктор (vvirus) 27.11.13 08:29
Благодарю, Вариант с удалением commit строки помог
94. Rajva (rajva) 24.12.13 18:58
Огромное спасибо этой ветке и всем кто отписывается здесь!

Удаление FileName = 'commit' не помогло, пришлось удалять еще и FileName = 'dbStruFinal'

Подскажите а "Тестирование и Исправление базы данных" после такого восстановления надо запускать?
95. Василий Мазурок (mvgfirst) 26.12.13 10:08
Фууухххх! Блин....
Спасли меня!!!

До нового года 4 дня! Продажи на максимуме и тут.... она падает...
Ночной бэкап есть... но с утра уже куча данных попала в базу...

Кажись выгреб ... из ситуации...
96. Андрей Коляда (Незнайка) 09.01.14 15:01
Да уж... спасибо огромное... спасли... хочется прямо N сумму куда-нибудь перечислить. Спасибо!!!
97. Эдуард - (wills) 16.01.14 00:16
Сегодня база 1с 8.2 SQL 2008 тоже рухнула, после того когда в ней на протяжении нескольких месяцев делали ДИНАМИЧЕСКОЕ обновление конфигурации, а затем просто заменили ее на аналогичную (сделали откат) - вот тут то и все рухнуло. Не стал запускаться даже конфигуратор, ругаясь таким сленгом, мол "Нарушена целостность данных" и все и никак и никуда не войти.. что только не пробовали, все бесполезно. Потом решил ее удалить и восстановить вчерашнюю, но она даже не удаляется!!! мол, структура базы нарушенна! ну все думаю, удалять в SQl надо, а не в 1S Servers. Перед этим думаю зайду в инет и полажу, мол чего пишут. Нашел пару СКЛ запросов и решил сделать таким образом:
1) сначала создал тестовую базу TEST на SQL загрузил в нее вчерашний *dt файл выгрузки и выполнил запрос, как описал выше VanDiesel1:

Use "полетевшая_база"
go
Delete From [DBO].[Config]
go
ins ert into ["полетевшая база"].[Dbo].[Config] sel ect * from ["TEST"].[Dbo].[Config]
go

2) попробовал запустить 1с и о ЧУДО она загрузилась в режиме предприятия, но в конфигуратор не заходит, та же проблема - "Нарушена целостность ...", тогда в путь второй запрос пойдет:

3) USE "РАБОЧАЯ_БАЗА"
GO
DR OP TABLE [dbo].[ConfigSave]
GO
SET ANSI_NULLS ON
GO
SE T QUOTED_IDENTIFIER ON
GO
CRE ATE TABLE [dbo].[ConfigSave](
[FileName] [nvarchar](128) NOT NULL,
[Creation] [datetime] NOT NULL,
[Modified] [datetime] NOT NULL,
[Attributes] [smallint] NOT NULL,
[DataSize] [int] NOT NULL,
[BinaryData] [image] NOT NULL,
PRIMARY KEY CLUSTERED
(
[FileName] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
INS ERT INTO ConfigSave
SELE CT * FR OM Config
GO

После этого и в конфигуратор вошел!!! ) так что можно и такой алгоритм пробовать! Всем удачи!

И еще раз совет: НИКОГДА, НИКОГДА ни делайте динамическое обновление конфигурации!!! на это вам и в 1с ничего не ответят, они сами видимо не знают что происходит.
98. Александр (Aragorn) 24.01.14 08:50
Спасибо, сильно выручили
99. apextrofimov (trand) 29.01.14 18:31
(7) asady, мне не помогло. Может кому-то пригодится. Я просто выполнил в pg_admin delete from configsave

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