Восстановление SQL базы 1С 8.2. рухнувшей во время сохранения конфигурации.
База данных - Архивирование (backup)
Предистория.
Два дня назад осуществили переход с 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. Это в последствии я узнал методом "самотыка" и опять же логики, ибо единственное что нашел это местную разработку, мне не помогшую но довольно полезную на будущее, а именно //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% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Поиск данных Инструменты администратора БД Корректировка данных Разработчик Бухгалтер Пользователь 1С:Предприятие 8 1С:Управление торговлей 10 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x 1С:Управление нашей фирмой 3.0 Россия Платные (руб)
Решение для автоматической сверки данных между любыми конфигурациями 1С. Помогает контролировать и проверять обмены, проверять наличие документов при переносах данных, находить изменения в закрытых периодах
9760 руб.
14.11.2025 6183 28 8
Задачи пользователя Инструментарий разработчика Корректировка данных Закрытие периода Разработчик Аналитик Бухгалтер Пользователь Руководитель проекта Стажер 1С 8.3 1С:ERP Управление предприятием 2 1С:Управление нашей фирмой 3.0 Управленческий учет Платные (руб)
Обработка предназначена для поиска, анализа и исправления отрицательных остатков во всех регистрах накопления информационной базы 1С.
6100 руб.
27.02.2026 3210 17 3
Закрытие периода Инструменты администратора БД Корректировка данных Бухгалтер Пользователь 1С:Предприятие 8 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Платные (руб)
Расширение «Оперативное проведение» в 4 раза уменьшает время проведения документов и закрытия месяца. Является комплексным решением проблем 62 и 60 счетов. Оптимизирует проведение при включенной функциональной опции «Раздельный учет НДС». Используется в более 10 организациях уже 2 года. Совместимо с конфигурацией Бухгалтерия 3.0 (+КОРП).
14640 руб.
29.04.2020 52963 145 164
Зарплата Корректировка данных Бухгалтер 1С 8.3 1С:Зарплата и кадры государственного учреждения 3 1С:Зарплата и Управление Персоналом 3.x Бухгалтерский учет НДФЛ Платные (руб)
Внешняя обработка сравнивает НДФЛ из расчетного листка и НДФЛ из регистра, на разницу формирует операцию учета НДФЛ. Исправляет расхождения, в том числе, когда Аванс больше Зарплаты Рассчитывает НДФЛ и сравнивает с исчисленным в программе. На отклонение формирует документ "Перерасчет НДФЛ"
9760 руб.
01.09.2023 10124 325 93
Корректировка данных Разработчик Пользователь 1С:Предприятие 8 1С:Управление торговлей 10 1С:Розница 2 1С:Управление производственным предприятием 1С:Управление нашей фирмой 1.6 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Управленческий учет Платные (руб)
Представьте, что есть система QR - кодирования, которая НЕ ТРЕБУЕТ изменения конфигурации, НЕ ТРЕБУЕТ изменения ни одной печатной формы для добавления QR-кода, включая внешние, НЕ ХРАНИТ данные штрихкодов и их связь, от чего база не "пухнет", ИМЕЕТ возможность закодировать в QR-коде произвольные данные параметров для последующей обработки полученных данных, УМЕЕТ прикреплять сканы, УМЕЕТ обработать считанный QR-код как ВЫ захотите. А также ХРАНИТ историю операций в обход базы для каждого пользователя в отдельности и УМЕЕТ работать с 2D - сканерами. А также автоматически распознавать отсканированные печатные формы (картинки или pdf-файлы) и выполнять заданные произвольные алгоритмы, в том числе прикрепление их к документам! Обновление 3.3 от 24.06.2025!
26840 руб.
26.08.2018 57643 20 65
Файловый обмен (TXT, XML, DBF), FTP Поиск данных Инструменты администратора БД Корректировка данных Системный администратор Разработчик 1С:Предприятие 8 1C:Бухгалтерия 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Платные (руб)
Данная обработка позволит Вам легко и просто, а главное - быстро, выполнить сравнение данных между ЛЮБЫМИ базами (и РИБ, по правилам конвертаций) по контрольным суммам выбранных объектов баз 1С, работающих на платформах 8.3 и выше. Удобный и понятный интерфейс в виде "мастера". Высокая скорость сравнения достигается за счет специального алгоритма расчета контрольной суммы объекта/записи и сравнения по данным суммам объектов 2х баз через файл. Имеется возможность выбора реквизитов, по которым система будет сравнивать объекты. Сравнение количества записей в движениях документов, возможность сравнивать данные по правилам конвертации и не только! Выбор объектов конфигурации для КАЖДОГО узла в отдельности с индивидуальным отбором для каждого объекта конфигурации, работа с FTP, сохранение или загрузка настроек, сохранение или загрузка результата сравнения, регистрация на обмен объекта и его движений. (Обновление от 12.11.2024, версия 2.2-2.5)
24400 руб.
27.10.2017 47848 33 15
Закрытие периода Корректировка данных Разработчик Пользователь 1С:Предприятие 8 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Управленческий учет Платные (руб)
Внешняя обработка, позволяющая произвольным образом заполнять документ "Корректировка регистров" Предназначена для использования в конфигурациях "Управление торговлей 11", "Управление небольшой фирмой", "ERP Управление предприятием", а также в других конфигурациях, в состав которых входит библиотека стандартных подсистем (БСП) версии 2.2+ и указанный выше документ.
5084 руб.
13.07.2015 55915 191 31
Корректировка данных Системный администратор Разработчик Аналитик Бухгалтер Пользователь Руководитель проекта 1С:Предприятие 8 1С:Управление торговлей 11 1С:Розница 3.0 1C:ERP 1С:ЗУП 1С:УТ Платные (руб)
Инструмент для анализа и устранения битых записей в регистрах 1С:Предприятия. Позволяет поддерживать целостность данных и повышает стабильность работы системы. Обработка предназначена для диагностики и корректировки ошибок в регистрах накопления и сведений. Обеспечивает контроль корректности данных и упрощает администрирование информационной базы. Решение для автоматизированного выявления и исправления записей в регистрах 1С. Снижает вероятность сбоев при расчётах и формировании отчётности.
5490 руб.
05.09.2025 2200 4 0
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
Можно склеить пункт 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 секунд, что для меня не очень критично.
УПП 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 в упавшей базе
базу удалось восстановить без потерь информации
Повезло в том что при злополучном обновлении конфигурации менялась только прикладная логика
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 в упавшей базе
базу удалось восстановить без потерь информации
Повезло в том что при злополучном обновлении конфигурации менялась только прикладная логика
я извиняюсь, а можете тупому объяснить вот эту часть строки '/home/user/config_1.txt ?
у нас просто ОС Windiws, как мне там написать, пример можете прислать на будущее?
а так у меня получилось восстановить эту таблицу такими действиями:
- в pg_admin delete from config
- открыл таблицы копии базы, там config сделал backup
- и у таблицы config упавшей базы сделал restore
если делать без удаления, то выдает ошибку что запись такая то уже есть
А в целом - респект!
При обновлении конфигурации конфигуратор завис, windows сказал что приложение будет закрыто. После этого в базу попасть никак не мог.
Пытался восстановить по инструкции , но ситуация не изменилась.
Так как это была копия рабочей БД решил поэкспериментировать.
Сравнил чем отличаются таблицы Config битой базы от целой. В битой базе были 2 записи, которых небыло в целой, с полями FileName = 'commit' и FileName = 'dbStruFinal' binaryData 0x0. Никакой информации об этих полях не нашел. Удалил эти записи. Запустил конфигуратор, он выдал предупреждение "Внимание!!! При обновлении данных, после последней реструктуризации, произошла критическая ошибка. Повторить обновление?" нажал "Да" и все обновилось.
Не знаю на что еще могло повлиять удаление.
Знал бы раньше этот прикуп - жил бы в Сочи :)
копия есть ночная, но она меня не сильно бы спасла, как раз сегодня менеджеры решили перебить кучу доков и в 10 рук непрерывно с сомого утра стучат по клавишам.
все больше никаких динамических
восстановил по вышеописанному скрипту:
Use Base2009
go
Delete From [DBO].[Config]
go
insert into [base2009].[Dbo].[Config] select * from [BaseCopy].[Dbo].[Config]
go
go
Delete From [DBO].[Config]
go
insert into [base2009].[Dbo].[Config] select * from [BaseCopy].[Dbo].[Config]
go
Шедевриальный скрипт!!!
Шикарно просто, ОГРОМНЕЙШЕЕ СПАСИБО за идею, до сих пор шок, как ваще такое может случиться....добавил в оборотно-сальдовую ведомость номера страниц блин........
1. Очищаем configsave
2. delete from config where FileName = 'commit'
3. delete from config where FileName = ' dbStruFinal'.
Запускаю 1С, все работает. Потом попробовал сохранить конфигурацию, все сохранилось, работаем уже на такой базе в течении 5-ти часов, полет нормальный, вариант кстати очень быстрый
insert into [Dbo].[Config]<Дата><Время> select * from [Dbo].[Config]
типа быстрый бекап cf-ника, ну а дальше мысль развивайте кто как хочет: можно на кнопку прикрутить к админскому интерфейсу, или программно определять, что это первый запуск(удачный) после пересборки(правда не знаю как, но мысль мне нравится). База при этом будет пухнуть и ее придется чистить переодически, но это уже другая история и всего лишь накладные расходы... Можно например создать под эти таблицы отдельный data-файл или вообще отдельную базу, не 1С-ную, под эти нужды(выдыхай борёр, выдыхай...)
Кому мысль нравится - ставим "+" коментарию не стесняясь.
Опишу свой случай. Конфигурация: ЗУП 2.5.51.1. Размер базы 16 Гб.
На днях произошла ситуация - делал динамическое обновление. Спустя 2 дня 2 сотрудника пожаловались,
что при формировании расчетных листков программа вылетает с сохранением дампа. Причем на других компьютерах под их учетками этого не происходило. Остальные пользователи не жаловались.
Пытался имитировать на своем компьютере. Парадоксов было куча.
В рабочей базе все работало. В текущей (получасовой) копии - вылетала.
При исправлении и тестировании базы конфигуратор закрывался.
Пришел к выводу, что при сохранении в базу любых изменений в структуре конфигурации конфигуратор закрывался.
С копиями баз проблем не было - были за каждый день.
Перепробовав все способы наткнулся на эту статью.
Но... перенос таблицы dbo.Config не дал результата, зато показал куда копать.
Спасло перенос 3-х таблиц: Config, DBSchema, Params
Так что автору rs_trade так же огромное спасибо!
Помогите пжл, уже голову сломала.
Догадывался, что так можно сделать, но без подтвержденного опыта не рискнул бы. А так юзеры курили около часа, пока тестовая копия жрала хранилице для создания нового прототипа 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
И еще небольшое наблюдения по подобным проблемам: лучше не сохранять сразу и рабочую конфигурацию, и конфу базы данных. Т.е. лучше сначала сохранить основную конфигурацию. А уже только после этого конфигурацию БД. Так ошибки появляются на порядок реже (если вообще появляются).
Выручил, уже не знал что делать с базой, вылетела в конце рабочего дня, а бэкап делается ночью, целый рабочий день 170 пользователей мог потеряться, меня бы расстреляли.. ))
Твой пост, реально помог.
После возникновения ошибки заметил зависшее несколько дней назад фоновое задание. думаю связано именно с этим. Так что перед обновлением убедитесь в отсутствие оных и включайте блокировку регламентных заданий.
1. Очищаем configsave
2. delete from config where FileName = 'commit'
3. delete from config where FileName = ' dbStruFinal'
Спасибо, помогло.
Согласен с Вами. В корректно обновленной конфигурации базы данных (таблица Config) таких строк быть не должно.
Пустая таблица ConfigSave означает, что она основная конфигурация не отличается от конфигурации базы данных.
Уйма времени ушла на создание бекапа. Минут 5 выполнялся запрос:
Use Base2009
go
Delete From [DBO].[Config]
go
insert into [base2009].[Dbo].[Config] select * from [BaseCopy].[Dbo].[Config]
go
Теперь работает! :)
спасибо :)
Очень-очень-очень помогла ваша статья, восстанавливали тестовую базу, конфигурацию, вылетела при обновлении и возникла описанная в статье ошибка, но благодаря вашей статье все хорошо
Тысяча спасибо :)
А если быть совсем добрым, то советую заглянуть
Исправлена ошибка:
10113064 Обновление конфигурации базы данных
Проблема:
Если процесс принятия изменений после обновления конфигурации базы данных был прерван, то на данную информационную базу может быть невозможно запустить ни в Предприятии, ни в Конфигураторе с различными сообщениями об ошибках или с аварийным завершением работы клиентского приложения или процессов сервера Предприятия.
Дата публикации:
2012-09-20
Это её наконец поправили?
При обновлении конфигурации записи из 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', но она в принципе не влияет на загрузку, удалится сама при очередном обновлении.
Без удаления этой строки 1С продолжал выдавать сообщения о незавершенном обновлении. При продолжении обновления вешался, при отмене завершал сеанс.
Во время динамического обновления вылезла такая же ошибка на 1С:УПП 8.2; MS SQL 2008;
восстановили другую конфигурацию по данному методу, кстати она тоже была изменена...Взлетело!
Удаление FileName = 'commit' не помогло, пришлось удалять еще и FileName = 'dbStruFinal'
Подскажите а "Тестирование и Исправление базы данных" после такого восстановления надо запускать?
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с ничего не ответят, они сами видимо не знают что происходит.
А на будущее состряпал себе скрипт - буду сохранять эти таблицы по расписанию:
СНАЧАЛА СДЕЛАТЬ БАКАП РАБОЧЕЙ БАЗЫ !!!!!
потом удалить DROP в рабоч. базе таблицы (Svitland.dbo.Config и Svitland.dbo.ConfigSave)
USE [1c82_tempBcp]
GO
IF EXISTS (SEL ECT * FR OM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[Config_SvitlandCopy]') AND type in (N'U'))
DR OP TABLE [dbo].[Config_SvitlandCopy]
GO
IF EXISTS (SEL ECT * FR OM sys.objects WH ERE object_id = OBJECT_ID(N'[dbo].[ConfigSave_SvitlandCopy]') AND type in (N'U'))
DR OP TABLE [dbo].[ConfigSave_SvitlandCopy]
GO
sel ect * into [1c82_tempBcp].dbo.Config_SvitlandCopy
from Svitland.dbo.Config
sel ect * into [1c82_tempBcp].dbo.ConfigSave_SvitlandCopy
fr om Svitland.dbo.ConfigSave Показатьи накидал 2й скрипт ВОССТАНОВЛЕНИЯ - чтобы потом не вспоминать синтаксис в спешке :)
и восстановить их из бакапа - для Свитлэнда:
/*
sel ect * into Svitland.dbo.Config
fr om [1c82_tempBcp].dbo.Config_SvitlandCopy
sel ect * into Svitland.dbo.ConfigSave
fr om [1c82_tempBcp].dbo.ConfigSave_SvitlandCopy
*/--------------------------------------------------------
PS блин при сохранении сообщения в словах select, drop и fr om пробелы добавляет :(
Сервер "1С:Предприятие 8.3 (8.3.4.496)"
БД "PostgreSQL 9.2.4-1.1C(x64)"
Не один из выше перечисленных способов не помог.
Помогла только полная переустановка сервера 1С, удаление (с полной чисткой реестра и временных каталогов).
После переустановки 1С база на которой была ошибка прекрасно стала сохраняться.
Замечание: в 1С:Предприятии 8.3 (8.3.5) в структуре таблицы config появилось еще одно поле PartNo.
С учетом этого скрипт принял вид:
GO
DR OP TABLE [БитаяБаза].[dbo].[Config]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CRE ATE 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,
[PartNo] [int] NOT NULL,
PRIMARY KEY CLUSTERED
(
[FileName] ASC,
[PartNo] 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 IN TO [БитаяБаза].[dbo].[Config]
SEL ECT * FR OM [ЦелаяБаза].[dbo].[Config]
GO ПоказатьУ меня ошибка стала возникать после сбоя при обновлении подчиненной РИБ. Очистка таблицы ConfigSave, и замена Config на таблицу из бэкапа проблему не решило.
Помогло удаление записей из таблицы DBChanges
Первые 2 пункта позволяют войти в конфигуратор, 3й пункт позволяет сохранять конфигурацию.
1) delete fr om configsave where FileName = 'commit'
2) delete from configsave wh ere FileName = 'dbStruFinal'
3) C:\Users\kub\AppData\Local\1C\1cv8 удаление всех папок кроме logs
Спасибо автору и всем отписавшимся в этой теме.
К сожалению, 1С ничего существенного не пишет по данной теме, а в первую очередь они должны быть заинтересованы.
ИМХО: Динамическое обновление - черная коробочка, открытия которой лучше избегать. Она как ящик Пандоры может бабахнуть.
delete from config where FileName = 'commit'
После этого, зашел в конфигуратор, минуя предупреждение "Внимание!!! При обновлении данных, после последней реструктуризации, произошла критическая ошибка. Повторить обновление?" ответом "ДА"
Далее, обновил конфу по F7.
варианты чистки таблицы config с именами поля FileName 'commit' и 'dbStruFinal' - безрезультатны. Тестирование и исправление - аналогично. Поиск прочих неправильных записей в config - аналогично
По результатам исследования помогло копирование таблицы param (натолкнуло на мысль ссылки в таблице param на файлы обновления)
DELETE FROM [ПроблемнаяБаза].[dbo].[Params]
GO
INS ERT IN TO [ПроблемнаяБаза].[dbo].[Params] SEL ECT * FR OM [РезервнаяБаза].[dbo].[Params]
GO
(в скрипте лишние пробелы - добавляются автоматом в сообщение)
Динамическое обновление. Сбой. Выполнена замена таблицы config и копии и очистка configSave.
Пользователи работают, в конфигуратор зайти можно.
НО.
Любая доработка программы и сохранение изменений приводит к повторению ошибки.
Места на дисках хватает. Кэш почистил.
Какую таблицу еще можно перенести из копии?
Сделал копию ломаной базы - открыл ее в конфигураторе - добавил константу - нажал - Обновить конфигурацию БД НА СЕРВЕРЕ.
И случилось чудо, пошла реструктуризация и изменения принялись. После этого удалить константу и сохранил как обычно F7 - все работает.
Кто знает, что это за режим? В инете про него ничего не нашел.
server_addr=tcp://1CSrv:1560 descr=10054(0x00002746): Удаленный хост принудительно разорвал существующее подключение. line=1582 file=d:\jenkins\ci_builder\windowsbuild2\platform\src\rtrsrvc\src\dataexchangetcpclientimpl.cpp'
При запуске конфигуратора ругается "Текущему соединению с информационной базой не назначен сеанс"
что делать не представляю.... помогите пожалуйста, за любую помощь буду благодарна.
не помогло копирование конфигурации
в конфигуратор пускает, НО ...... запускается выдает отсутствие таблиц Node ...., потом еще и еще ругается
тестирование не очень помогает
помогло только вот это
delete fr om config wh ere FileName = 'dbStruFinal'
""fr om и wh ere - без пробелов
Тут понадобилось выгрузить конфигурацию в файл, при выгрузке почти в конце прогресса выходит ошибка
Файл не обнаружен 'v8srvr://c19a9789-d8f9-4ae6-bc8e-a5a271ee8a49/upp/Config/versions_dynupdate_f43beffb-35a0-4c7a-984e-7b1db4585f89'
по причине:
Файл не обнаружен 'upp/Config/versions_dynupdate_f43beffb-35a0-4c7a-984e-7b1db4585f89'
Т.е. явно надо чистить ссылки на кривые обновления способом из этой темы
В этой
написано, что:
==
Все объекты, которые вы изменяли в конфигурации хранятся в таблице configsave.
При обновлении происходит сначала заполнение таблицы configsave, после чего данные переносятся в таблицу config, стираясь с предыдущего места.
Вы можете воспользоваться возможностью скопировать таблицу config из идентичной базы в неработающую или, как вариант, удалить все найденные изменения.
==
Т.е.
dbo.ConfigSave - это то, что внесено в конфигурацию, но ещё неприменено
dbo.Config - это то, что уже полностью внесено (перенесено из dbo.ConfigSave )
если в строке есть "dynupdate" - значит обновление динамическое
если в строке есть "dynamicCommit" - значит обновление динамическое и подтверждённое
Обновлений, содержащих "Commit" ни в одной таблице (dbo.ConfigSave и dbo.Config)нет, значит все обновления, включая динамические уже внесены в конфигурацию.
А вот обновления, содержащие "dynupdate" есть в таблице dbo.Config есть, их там 25 шт., из них 10 содержат id из ошибки - "f43beffb-35a0-4c7a-984e-7b1db4585f89" Вот на них ошибка и указывает.
В статье говорится что нужно удалить всё, что имеет в строке "dynamicCommit" или "Commit". Но это для случаев, когда 1С не запускается, ругаясь на обновление. У нас другой случай - всё запускается, ругается только при выгрузке конфигурации в файл.
Вопрос - в таблице dbo.Config вообще могут присутствовать строки, содержащие "dynupdate", если никаких не применённых обновлений уже нет?
По идее, если все обновления уже внесены в базу, то строки с "dynupdate", "dynamicCommit" "Commit" вообще не должны никак влиять на конфигурацию да и не должны там присутствовать. Т.е. их можно смело удалить.
Так?
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 116123
Создание 08.02.12 17:16
Обновление 18.04.12 13:56
Просмотры 151316
Загрузки 0
Рейтинг
383
Комментарии 143
Код открыт Не указано
Рубрики Корректировка данных Архивирование (backup)
Кому
Системный администратор
,
Разработчик
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация 1C:Бухгалтерия
Операционная система Не имеет значения
Страна Россия
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
