Ошибка при реструктуризации базы |
Я |
trim89
14.06.19 — 05:00
Доброго времени суток.
Стал замечать что перестала автоматом обновляться конфигурация базы. Попытался обновить вручную, на этапе реструктуризации вышла ошибка
Недопустимое состояние объекта
[backend — srcRestructInfoStorage.cpp (792)]
База серверная, SQL. Кэш чистил, 1с сносили и переустанавливали, ТИИ делать не могу, так как эта ошибка, даже dt выгрузить не могу. С остальными базами всё в порядке.
Куда копать, что смотреть?
ЛЮС
1 — 14.06.19 — 07:09
Выгрузить сф-ник, развернуть отдельно демо базу, накатить на нее сф-ник. Если там ошибка сохранится — проблема в конфигурации, если нет — в данных.
Можно попробовать выявить на реструктуризации чего он падает — маловероятно, но вдруг прокатит.
Попробовать запустить копию базы на новой платформе на другом сервере. Тоже может прокатить.
В самых запущенных случаях делали так: брали конфу поставщика, ручками переносили все наработки в нее. Разворачивали новую пустую базу и переносили данные из боевой в эту новую. Долгий вариант.
trim89
2 — 14.06.19 — 07:48
(1) cf-ник пока выгружаю/загружаю. «Можно попробовать выявить на реструктуризации чего он падает» — а как это делать?
rphosts
3 — 14.06.19 — 07:56
(0) бэкэнд? платформа на сервере поди патченная?
rphosts
5 — 14.06.19 — 07:57
Попробуй подключить эту базу к другому серверу СУБД
Cyberhawk
6 — 14.06.19 — 08:09
Расширения есть?
ЛЮС
7 — 14.06.19 — 08:14
(2) при реструктуризации в строке состояния пишется имя таблицы (не всегда актуальное, но все-таки). Можно в скуле смотреть создание таблиц с постфиксом *_NG
trim89
8 — 14.06.19 — 08:14
(6) Есть, но опять таки, тестовая — почти копия, с ней всё ок (3) Вроде да, но с другими всё нормально
trim89
9 — 14.06.19 — 08:16
(7) Не доходит до того как пишет имя таблицы. Загрузил cf в новую базу, всё работает.
Cyberhawk
10 — 14.06.19 — 08:17
(8) Ну так дело конечно же в них тогда. Столько уже сообщений по этому поводу.
shuhard
11 — 14.06.19 — 08:18
(10) при выгрузке dt расширение ?
Cyberhawk
12 — 14.06.19 — 08:21
(11) Конечно, ведь при сем действе тоже кое-чего происходит (база меняет свое состояние)
Сияющий в темноте
13 — 14.06.19 — 08:45
в расширении,поди,реквизиты в обьекты добавляли?
тут даже не делает лучше,чем делает и сносит таблицы с данными в никуда
trim89
14 — 14.06.19 — 08:48
(13) Попробую снести все расширения
trim89
15 — 14.06.19 — 09:04
(13) (12) (10) Хм, действительно. Снял галку активно в расширении, куда регистр добавлял, вроде заработало. Сейчас заново копию скульную восстановлю, ещё раз попробуй для чистоты эксперимента.
ice777
16 — 14.06.19 — 09:07
(15) а как мне про эти расширения в уши жужжали! фтопку их, короче.)
trim89
17 — 14.06.19 — 09:26
(16) Не, они хороши, что касается изменения, доработки кода. А объекты метаданных добавлять стоит в крайнем случае.
trim89
18 — 17.06.19 — 02:58
В общем, восстановил ещё раз, удалил расширения. Вылезла ошибка, мол «Ошибка обновления», обновил ещё раз — получилась реструктаризация. Теперь снова проблема, если добавить новый объект метаданных, всё обновляется, но если в режиме предприятия зайти в данный документ/справочник/регистр то будет ошибка «Запись не найдена в менеджере имен базы данных».
Попытаюсь на другой платформе открыть, очень сильно надеюсь, что это баг именно платформы.
trim89
19 — 18.06.19 — 10:39
Получилось только так. В режиме предприятия снимаю галку активно с расширения. Пытаюсь его удалить, выдаёт ошибку «попытка переключить менеджер имен базы данных без сохранения информации», он не удаляется. После этого лезу в конфу и чудо!!!! можно делать реструктаризацию, при добавлении метаданных нет ошибки «Запись не найдена в менеджере имен базы данных».
Фишка в том, что 1) нужно попытаться расширение удалить 2) не нужно расширение окончательно удалять.
Расширение будет висеть, пока не знаю как его грохнуть. Попробую позже через скуль.
Нам всем знакомо, как долго может идти обновление: это может занимать несколько часов, а в некоторых случаях – даже
несколько дней.
Однако, его можно заметно ускорить. А для этого нужно немного погрузиться в детали и поговорить о реструктуризации
Когда в 1С изменяются метаданные (добавляются документы, реквизиты, индексы), происходит изменение структуры таблиц.
При запуске обновления создается полная копия таблицы, включая индексы – уже с новой структурой. Этот процесс называется реструктуризацией. Разумеется, это все занимает довольно заметное время.
Для случаев, когда объемы данных небольшие, это не так чувствительно.
Но реструктуризация больших баз, в которых содержатся таблицы с десятками миллионов строк, может затянуться на несколько часов или даже дней. Потеря такого количества времени – это уже весьма болезненно.
Еще в платформе 8.3.11 появился механизм, который помогает ускорить реструктуризацию в разы, а в некоторых случаях – на порядки.
С момента выхода этого релиза прошло уже 5 лет, но, судя по вопросам в Мастер-группе, до сих пор многие не знакомы с этим механизмом и не знают о его преимуществах.
Сегодняшнее видео закрывает этот вопрос:
- Объясняем, чем механизм, который появился в 8.3.11, отличается от стандартного способа реструктуризации
- Показываем, как настроить и использовать новый механизм
- Демонстрируем его преимущества и рассказываем о его недостатках
- Объясняем, кому необходим этот механизм, а кому переходить на него не стоит.
Если Вы недовольны тем, с какой скоростью проходит реструктуризация в ваших базах, это видео обязательно к просмотру.
Но даже если Вы работаете в маленькой компании и с этой проблемой еще не столкнулись – рекомендуем все-таки найти 17 минут и посмотреть его. Если завтра Вы поменяете работу и столкнетесь с такой проблемой – не придется волноваться из-за того, что Вы не в курсе таких нюансов.
Ключевые моменты видео:
- 00:00 – Постановка задачи
- 00:28 – Старый способ реструктуризации и его недостатки
- 01:50 – Новый способ реструктуризации
- 02:17 – Плюсы нового способа
- 03:04 – Установка Java на сервер 1С
- 04:18 – Настройка файла conf.cfg на клиенте
- 05:40 – Демонстрация работы старого механизма
- 07:36 – Демонстрация работы нового механизма
- 08:58 – Особенности использования нового механизма
- 09:10 – Включение протокола TCP/IP для СУБД
- 10:52 – Проверка сторонних индексов
- 13:20 – Настройка параметра MAXDOP в MS SQL
- 16:36 – Итоги
После курса Вы сможете:
- Оценивать состояние системы в любой момент времени
- Быстро находить причины замедления в программном коде – и сразу писать его так, чтобы замедления в будущем не было
- Отслеживать динамику производительности за определенный период
- Устранять ожидания на блокировках и решать проблемы со взаимоблокировками
Для кого этот курс
Вам нужен этот курс, если Вы хотите:
- Писать код, за который не стыдно – в нестабильное время особенно важно быть в компании на хорошем счету
- Быть востребованным специалистом – на каждом втором собеседовании спрашивают про умение оптимизировать 1С
- Не терять клиентов из-за того, что «ваша 1С тормозит, а вы ничего не делаете» – это и раньше было нехорошо, а теперь и вовсе непозволительная роскошь.
При обновлении данных, после последней реструктуризации, произошла критическая ошибка. Повторить обновление?
20 июня, 2019
20 июня, 2019
Дано
При применении конфигурации в РИБ возникает критическая ошибка и конфигуратор аварийно завершается.
Затем, при попытке зайти в конфигуратор, 1С выдает следующее сообщение: “При обновлении данных, после последней реструктуризации, произошла критическая ошибка. Повторить обновление?”
Выбор любого из действий ни к чему не приводит и если ответить утвердительно, то повтор обновления не происходит.
Попытка вернуться к конфигурации БД через параметр командной строки /RollbackCfg так же не увенчалась успехом. При использовании этого метода в диспетчере задач видно, что 1С запускается на 2-3 секунды и даже не успевает развернуться в памяти, и фактически не отрабатывает.
Версия платформы 8.3.13.1809 (клиент-сервер)
Решение
На просторах интернета конечно же есть решение, которое реально помогает, но нужно заметить его небезопасность и то, что все действия нужно выполнять с осторожностью перепроверяя свои действия.
Итак суть решения состоит в том чтобы очистить некоторые данные в таблицах БД (SQL), которые говорят системе о незавершенном обновлении. Нужно выполнить запросы к БД.
Конечно же я настоятельно рекомендую выполнять все действия при наличии резервной копии БД, причем средствами сервера БД. Но если на это нет времени, то мы себя немного обезопасим резервной копией таблиц.
|
select * into Config_tmp from Config select * into ConfigSave_tmp from ConfigSave delete from ConfigSave delete from config where FileName = ‘commit’ delete from config where FileName = ‘dynamicCommit’ delete from config where FileName = ‘dbStruFinal’ |
Кстати о возможности возврата к отправной точке, первые два select копируют две таблицы, с которыми мы будем выполнять действия и создают временные таблицы Config_tmp и ConfigSave_tmp на всякий случай для возможности возврата.
первый из delete удаляет все данные таблицы ConfigSave.
остальные удаляют определенные записи из таблицы config.
После выполнения этих действий вы сможете зайти в 1С в режиме конфигуратора, при этом все ваши изменения будут потеряны.
Если все прошло удачно, то нужно удалить временные таблицы которые мы создавали.
|
drop table Config_tmp drop table ConfigSave_tmp |
Собственно это решение было найдено в интернете и протестировано в реальных условиях и показало результат. Огромное спасибо тому кто потратил время, на изучение этого вопроса и поделился этой информацией.
Пару раз уже случалось увидеть такую надпись при обновлений конфигурации 1С. Причем не важно на какой платформе, что на 8.3.6, что на более новых 8.3.12. И что то мне кажется, что эта еще одна причуд системы, обычными методами в виде галочек, кнопочек и других атрибутов интерфейса, реализовано в ближайшее время не будет.
И мы остаемся с возможностью увидеть такое:
Чтобы не искать в следующий раз, запишу заметку на будущее.
С файловыми базами я не работаю, по этому и проблем как таковых для меня нет. Если возникают проблемы:
— Чистим кеш на локальном компьютере.
— Запускаем обработку chdbfl.exe для проверки конфигурации.
— Если не помогло, лезем в файлы базы. Находим обработку Tool_1CD.exe и с помощью ее редактируем файлы
— Есть метод описанный в статье https://infostart.ru/public/182889/
Фактически таблицы SQL базы и файловой не отличаются. По этому переходим к описанию действий на SQL:
— сперва смотрим, что есть в таблице dbo.configsave. Если что то там есть, удаляем : delete from configsave
— далее, если запустить profiler первое сообщение в 1С выводится после запроса select * from Config WHERE FileName = ‘commit’. Удаляем, чтобы сообщение не выводилось: delete from config where FileName = ‘commit’
— так же сообщение выводится после запроса select * from Config WHERE FileName = ‘dbStruFinal’. Удаляем тоже его: delete from config where FileName = ‘dbStruFinal’
Подводим итог:
Все изменения хранятся в таблице configsave. Если она пуста, а присутствует флаг для обновления конфигурации, данные копируются в таблицу config и следовательно затирают пустыми.
Список команд в SQL которые нужно выполнить последовательно,для того чтобы отменить обновление:
—delete from configsave
—delete from config where FileName = ‘commit’
—delete from config where FileName = ‘dynamicCommit’
—delete from config where FileName = ‘dbStruFinal’
Напоминаю, изложение данного материала не являются призывом к действию, а служит только для информации и ознакомления, которую читатель вправе сам выбирать, использовать или нет. Спасибо.
В процессе обновления информационной базы произошла критическая ошибка по причине: Ошибка СУБД: Microsoft SQL Server Native Client 11.0: Не удалось вставить значение NULL в столбец таблицы «.dbo.»; в столбце запрещены значения NULL. Ошибка в INSERT.
Описание ошибки:
Столкнулся с ошибкой при выполнении процедуры Тестирование и исправление… на этапе реструктуризации таблиц информационной базы. База клиент-серверная. 1С: Управление торговлей 10.3.31. Платформа 1С: Предприятие 8.3.9
Найденные решения:
Сложно сказать, что посчастливилось, но все же ошибка преследовала меня в базе не единожды. Но по своей сути каждая последующая формулировка «В процессе обновления информационной базы произошла критическая ошибка…» отличалсь в причине и решении незначительно. С такой ошибкой столкнулся, если быть откровенным, впервые, но интернет в принятии решения устранения ошибки сильно не помог, кроме вот этого обсуждения на форуме Как удалить строки содержащие NULL в таблице где NULL недопустимо. Зацепок решения не было. Но все же решение было найдено. Читаем… ниже.
Итак, начнем с первого факта возникновения ошибки при выполнении тестирования и исправления базы данных на этапе реструктуризации таблиц базы данных.
Кнопка «Подробно…»:
Полный текст ошибки:
В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка СУБД:
Microsoft SQL Server Native Client 11.0: Не удалось вставить значение NULL в столбец «_Fld412», таблицы «Торговля.dbo._Reference19NG»; в столбце запрещены значения NULL. Ошибка в INSERT.
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=2, Severity=10, native=515, line=1
Если взглянуть скрином ранее, то нельзя упустить из виду подсказку, оставленую программой в левом нижнем углу окна программы, в строке состояния, о том, что выполнение реструктуризации прервалось на справочнике «Банковские счета». В базе справочник имел более 3х с половиной тысяч элементов, поэтому сходу было сложно понять, в каком из них скрывается ошибка. Была написана простая обработка, которая просто должны была обойти все элементы справочника и перезаписать их. Надежда была на то, что запись проблемного элемента завершиться ошибкой.
Исполняемый код обработки прост:
Запрос = Новый Запрос;
Запрос.Текст = «ВЫБРАТЬ
| БанковскиеСчета.Ссылка
|ИЗ
| Справочник.БанковскиеСчета КАК БанковскиеСчета»;
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
СпрОбъект = Выборка.Ссылка.ПолучитьОбъект();
СпрОбъект.Записать();
КонецЦикла;
Предположение было оправдано. Ошибка при записи возникла. Теперь было понятно, элемент с каким кодом может быть причиной критической ошибки в процессе обновления информационной базы.
Это оказался элемент справочника, у которого не был заполнен ни одни реквизит, так что мне даже не удавалось пометить такой элемент на удаление. Дальше была написана простая обработка для удаления выбранного элемента справочника без проверки ссылочной целостности. Элемент был удален.
Тестирование и исправление было запущено повторно. Но уже вскоре после запуска процедуры в режиме реструктуризация таблиц базы мен ожидала идентичная ошибка, но уже связанная со справочником «Организации».
Новый текст ошибки отличался лишь немногим, названием таблицы и именем столбца:
В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка СУБД:
Microsoft SQL Server Native Client 11.0: Не удалось вставить значение NULL в столбец «_Fld888», таблицы «Торговля.dbo._Reference66NG»; в столбце запрещены значения NULL. Ошибка в INSERT.
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=2, Severity=10, native=515, line=1
По опыту предыдущей инцидента уже казалось понятным, что в справочнике у какого-то элемента не заполнены данные. Так и оказалось. Проблемный элемент справочника был найден мгновенно и в этом случае повезло больше элемент можно было пометить на удаление, был помечен и удален с помощью «Удаление помеченных объектов».
Тестирование и исправление было запущено в третий раз. Но и этот раз не обошелся без «критической ошибки в процессе обновления информационной базы».
Текст третьей ошибки:
В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка СУБД:
Microsoft SQL Server Native Client 11.0: Не удалось вставить значение NULL в столбец «_Fld1024RRef», таблицы «Торговля.dbo._Reference88NG»; в столбце запрещены значения NULL. Ошибка в INSERT.
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=2, Severity=10, native=515, line=1
Но и в этот раз программа оставила подсказку, что проблема содержится в записях справочника «ТипыЦенНоменклатурыКонтрагентов».
Удалить проблемные элементы справочника пришлось программно с помощью все той же, указанной выше простой обработки непосредственного удаления без проверки ссылочной целостности.
И в итоге очередной запуск, уже четвертый по счету, в режиме «Реструктуризация таблиц информационной базы» в рамках тестирования и исправления завершился успешно.
Оцените, помогло ли Вам предоставленное описание решения ошибки?
© www.azhur-c.ru 2014-2020. Все права защищены. Использование текстов и изображений с данной страницы без письменного разрешения владельца запрещено. При использовании материалов с данной страницы обязательно указание ссылки на данную страницу.
31-10-2018
Журавлев А.С.
(Сайт azhur-c.ru)
Внимание!!! При обновлении данных, после последней реструктуризации, произошла ошибка. Повторить обновление?
Опубликовано: 16.02.2018 /
Переезжали мы на новый сервер. На нем SQL и 1C. В сравнении со старыми был намного круче. И тест Гилева это тоже подтвердил: против 10-15 на старых серверах выдавал 39. Поэтому мы сразу после покупки перенесли базу и начали работу.
Но в какой-то момент что-то пошло не так — пользователи стали жаловаться на медленную работу. Произвели определенные настройки сервера и служб (какие — тема отдельного поста) и решили перезагрузить сервер, благо скорость перезагрузки — 2 минуты (на других серверах до 10 доходило). После этого при входе в 1С получаем следующее сообщение:
«Внимание!!! При обновлении данных, после последней реструктуризации, произошла ошибка. Повторить обновление?» «Да, Нет»
После нажатия кнопки «Да» появляется следующее:
«Обнаружена незавершенная операция сохранения конфигурации. Для продолжения работы необходимо завершить операцию.»
Первое, что решил сделать — CHECKDB на в Managment Studio — после 2х часов ожидания (база 500 ГБ) — все ОК.
На просторах сети нашел информацию, что такая же ошибка бывает при динамическом обновлении.
Решения, предложенные в сети сходу не помогли, но вкупе с другими действия дали результат. Итак, что я делал:
Решение:
- То, чего не хватало для решений из сети:
sp_configure ‘allow updates’, 1
reconfigure with override
go
2. Переводим базу в режим восстановления
alter database [db_name] set EMERGENCY, SINGLE_USER
3. Выполняем тестирование базы:
dbcc checkdb(‘db_name’, REPAIR_ALLOW_DATA_LOSS )
4. Выводим базу из режима восстановления:
alter database [db_name] set ONLINE, MULTI_USER
5. В принципе, если уверены что с самой базой все ок, то можно не делать 2-4 пункты. Далее выполняем два запроса в профайлере SQL:
delete from config where FileName = ‘commit’
delete from config where FileName = ‘ dbStruFinal’Эти записи и отвечают за динамическое обновление — можно не бояться их удалять.
В рабочих версиях баз запросы:
select * from Config WHERE FileName = ‘commit’
select * from Config WHERE FileName = ‘dbStruFinal’
будут пустые.
6. возвращаем настройки:
sp_configure ‘allow updates’, 0
go
7. После этого удалось запустить конфигуратор и база заработала.
Также база может заработать после удаления первого флага.
Еще из решений, которые есть в сети, полная замена таблицы Config.
Что у меня использовалось:
Платформа 1С: 1С:Предприятие 8.3 (8.3.10.2466)
SQL: Microsoft SQL Server 2008 R2 Standard Edition (64-bit) 10.50.6220.0
Также обратил внимание, что проблема повторяется на всех версиях платформ и SQL.
Всем удачи с решением таких проблем. Если есть трудности, обращайтесь, помогу.
p.s. бекап был, но терять даже несколько часов работы не очень хотелось
Ошибка при реструктуризации базы |
Я |
14.06.19 — 05:00
Доброго времени суток.
Стал замечать что перестала автоматом обновляться конфигурация базы. Попытался обновить вручную, на этапе реструктуризации вышла ошибка
Недопустимое состояние объекта
[backend — srcRestructInfoStorage.cpp (792)]
База серверная, SQL. Кэш чистил, 1с сносили и переустанавливали, ТИИ делать не могу, так как эта ошибка, даже dt выгрузить не могу. С остальными базами всё в порядке.
Куда копать, что смотреть?
1 — 14.06.19 — 07:09
Выгрузить сф-ник, развернуть отдельно демо базу, накатить на нее сф-ник. Если там ошибка сохранится — проблема в конфигурации, если нет — в данных.
Можно попробовать выявить на реструктуризации чего он падает — маловероятно, но вдруг прокатит.
Попробовать запустить копию базы на новой платформе на другом сервере. Тоже может прокатить.
В самых запущенных случаях делали так: брали конфу поставщика, ручками переносили все наработки в нее. Разворачивали новую пустую базу и переносили данные из боевой в эту новую. Долгий вариант.
2 — 14.06.19 — 07:48
(1) cf-ник пока выгружаю/загружаю. «Можно попробовать выявить на реструктуризации чего он падает» — а как это делать?
3 — 14.06.19 — 07:56
(0) бэкэнд? платформа на сервере поди патченная?
5 — 14.06.19 — 07:57
Попробуй подключить эту базу к другому серверу СУБД
6 — 14.06.19 — 08:09
Расширения есть?
7 — 14.06.19 — 08:14
(2) при реструктуризации в строке состояния пишется имя таблицы (не всегда актуальное, но все-таки). Можно в скуле смотреть создание таблиц с постфиксом *_NG
8 — 14.06.19 — 08:14
(6) Есть, но опять таки, тестовая — почти копия, с ней всё ок (3) Вроде да, но с другими всё нормально
9 — 14.06.19 — 08:16
(7) Не доходит до того как пишет имя таблицы. Загрузил cf в новую базу, всё работает.
10 — 14.06.19 — 08:17
(8) Ну так дело конечно же в них тогда. Столько уже сообщений по этому поводу.
11 — 14.06.19 — 08:18
(10) при выгрузке dt расширение ?
12 — 14.06.19 — 08:21
(11) Конечно, ведь при сем действе тоже кое-чего происходит (база меняет свое состояние)
13 — 14.06.19 — 08:45
в расширении,поди,реквизиты в обьекты добавляли?
тут даже не делает лучше,чем делает и сносит таблицы с данными в никуда
14 — 14.06.19 — 08:48
(13) Попробую снести все расширения
15 — 14.06.19 — 09:04
(13) (12) (10) Хм, действительно. Снял галку активно в расширении, куда регистр добавлял, вроде заработало. Сейчас заново копию скульную восстановлю, ещё раз попробуй для чистоты эксперимента.
16 — 14.06.19 — 09:07
(15) а как мне про эти расширения в уши жужжали! фтопку их, короче.)
17 — 14.06.19 — 09:26
(16) Не, они хороши, что касается изменения, доработки кода. А объекты метаданных добавлять стоит в крайнем случае.
18 — 17.06.19 — 02:58
В общем, восстановил ещё раз, удалил расширения. Вылезла ошибка, мол «Ошибка обновления», обновил ещё раз — получилась реструктаризация. Теперь снова проблема, если добавить новый объект метаданных, всё обновляется, но если в режиме предприятия зайти в данный документ/справочник/регистр то будет ошибка «Запись не найдена в менеджере имен базы данных».
Попытаюсь на другой платформе открыть, очень сильно надеюсь, что это баг именно платформы.
trim89
19 — 18.06.19 — 10:39
Получилось только так. В режиме предприятия снимаю галку активно с расширения. Пытаюсь его удалить, выдаёт ошибку «попытка переключить менеджер имен базы данных без сохранения информации», он не удаляется. После этого лезу в конфу и чудо!!!! можно делать реструктаризацию, при добавлении метаданных нет ошибки «Запись не найдена в менеджере имен базы данных».
Фишка в том, что 1) нужно попытаться расширение удалить 2) не нужно расширение окончательно удалять.
Расширение будет висеть, пока не знаю как его грохнуть. Попробую позже через скуль.
Прошло немало времени, и все же хотелось бы продолжить и поделиться мало ли кому поможет.
Текущая платформа 1С 8.3.13.1690, все остальные технические параметры остались прежними и ничего не менялось.
(экспериментировать с другими версиями платформы не стал, так как на этой версии сидим давно и вроде бы все работало же….)
Конфигурация до недавнего времени находилась как было описано выше в режиме совместимости 8.3.10, благодаря чему реструктуризация из под конфигуратора проходила штатно и не превносила сюрпризов, казалось бы жили да жили так дальше без новых возможностей…
Месяц назад, после очередной такой реструктуризации которая прошла штатно поломалась часть объектов (при чем уже более значительная, открытие которых в режиме 1С приводило к SDBL разного рода), час икс настал 
благо это случилось в выходной день. Откат базы к бэкапу недельной давности, наращивание логами транзакции до момента поломки. Выгрузка в DT которая кстати проходит штатно как и выгрузка CF как и загрузка того и другого обратно.
Поднял тестовую базу и начал экспериментировать (на боевой запретил все регламенты по реструктуризации и пересчетам итогов по выходным), в итоге пришлось полностью убить все имеющиеся планы обмена (выгрузка CF удаление всех планов обмена, сравнением объединение с CF чтобы планы обмена вернулись обратно и до настройка их в 1С), так как оказалось в них откуда то взялись данные зарегистрированные для узла ЭтотУзел (подозреваем это привнесла одна из платформ так как там находилась часть данных а не все что могло бы туда попасть за прошлые года). Пришлось лишиться записей в регистре сведений «История изменений» — самопальный механизм которые регистрировал любые настроенные изменения любых настроенных объектов (изменения реквизитов или табличных частей) — в этом регистре были сотни миллионов записей, штатно очистить не представлялось возможным из за недостатка времени, поэтому TRUNCATE TABLE на SQL решил проблему моментально.
После долгих мучений в итоге (спасибо предыдущему посту про обновление на сервере) конфигурация была снята с режима совместимости 8.3.10 и обновлена на сервере (не через штатную кнопку обновления — через штатную крашилось при реструктуризации), что прошло в принципе достаточно быстро, далее открытие режима 1С предприятия, проверка всех объектов — все работает (чудо не иначе). Возвращаемся в конфигуратор, реструктуризация через ТиИ — все проходит.
Что это было остается догадываться, возможно оно до сих пор сидит в базе, но сейчас все работает.
Всем удачи я поделился исключительно своим опытом и своими «колдобинами» при мучении с базой объемом под 300 гб, и не настаиваю что всем это поможет, но в друг кому то пригодится .
Пару раз уже случалось увидеть такую надпись при обновлений конфигурации 1С. Причем не важно на какой платформе, что на 8.3.6, что на более новых 8.3.12. И что то мне кажется, что эта еще одна причуд системы, обычными методами в виде галочек, кнопочек и других атрибутов интерфейса, реализовано в ближайшее время не будет.
И мы остаемся с возможностью увидеть такое:
Чтобы не искать в следующий раз, запишу заметку на будущее.
С файловыми базами я не работаю, по этому и проблем как таковых для меня нет. Если возникают проблемы:
— Чистим кеш на локальном компьютере.
— Запускаем обработку chdbfl.exe для проверки конфигурации.
— Если не помогло, лезем в файлы базы. Находим обработку Tool_1CD.exe и с помощью ее редактируем файлы
— Есть метод описанный в статье https://infostart.ru/public/182889/
Фактически таблицы SQL базы и файловой не отличаются. По этому переходим к описанию действий на SQL:
— сперва смотрим, что есть в таблице dbo.configsave. Если что то там есть, удаляем : delete from configsave
— далее, если запустить profiler первое сообщение в 1С выводится после запроса select * from Config WHERE FileName = ‘commit’. Удаляем, чтобы сообщение не выводилось: delete from config where FileName = ‘commit’
— так же сообщение выводится после запроса select * from Config WHERE FileName = ‘dbStruFinal’. Удаляем тоже его: delete from config where FileName = ‘dbStruFinal’
Подводим итог:
Все изменения хранятся в таблице configsave. Если она пуста, а присутствует флаг для обновления конфигурации, данные копируются в таблицу config и следовательно затирают пустыми.
Список команд в SQL которые нужно выполнить последовательно,для того чтобы отменить обновление:
—delete from configsave
—delete from config where FileName = ‘commit’
—delete from config where FileName = ‘dynamicCommit’
—delete from config where FileName = ‘dbStruFinal’
Напоминаю, изложение данного материала не являются призывом к действию, а служит только для информации и ознакомления, которую читатель вправе сам выбирать, использовать или нет. Спасибо.
При обновлении данных, после последней реструктуризации, произошла критическая ошибка. Повторить обновление?
20 июня, 2019
20 июня, 2019
Дано
При применении конфигурации в РИБ возникает критическая ошибка и конфигуратор аварийно завершается.
Затем, при попытке зайти в конфигуратор, 1С выдает следующее сообщение: “При обновлении данных, после последней реструктуризации, произошла критическая ошибка. Повторить обновление?”
Выбор любого из действий ни к чему не приводит и если ответить утвердительно, то повтор обновления не происходит.
Попытка вернуться к конфигурации БД через параметр командной строки /RollbackCfg так же не увенчалась успехом. При использовании этого метода в диспетчере задач видно, что 1С запускается на 2-3 секунды и даже не успевает развернуться в памяти, и фактически не отрабатывает.
Версия платформы 8.3.13.1809 (клиент-сервер)
Решение
На просторах интернета конечно же есть решение, которое реально помогает, но нужно заметить его небезопасность и то, что все действия нужно выполнять с осторожностью перепроверяя свои действия.
Итак суть решения состоит в том чтобы очистить некоторые данные в таблицах БД (SQL), которые говорят системе о незавершенном обновлении. Нужно выполнить запросы к БД.
Конечно же я настоятельно рекомендую выполнять все действия при наличии резервной копии БД, причем средствами сервера БД. Но если на это нет времени, то мы себя немного обезопасим резервной копией таблиц.
select * into Config_tmp from Config select * into ConfigSave_tmp from ConfigSave delete from ConfigSave delete from config where FileName = 'commit' delete from config where FileName = 'dynamicCommit' delete from config where FileName = 'dbStruFinal'
Кстати о возможности возврата к отправной точке, первые два select копируют две таблицы, с которыми мы будем выполнять действия и создают временные таблицы Config_tmp и ConfigSave_tmp на всякий случай для возможности возврата.
первый из delete удаляет все данные таблицы ConfigSave.
остальные удаляют определенные записи из таблицы config.
После выполнения этих действий вы сможете зайти в 1С в режиме конфигуратора, при этом все ваши изменения будут потеряны.
Если все прошло удачно, то нужно удалить временные таблицы которые мы создавали.
drop table Config_tmp drop table ConfigSave_tmp
Собственно это решение было найдено в интернете и протестировано в реальных условиях и показало результат. Огромное спасибо тому кто потратил время, на изучение этого вопроса и поделился этой информацией.
вылетел конфигуратор при обновлении , терь не могу ни в конф ни в предприятие !! |
Я |
BigShmax
18.10.12 — 10:40
Запускаю конфигуратор , пишет :
Внимание!! при обновлении данных после последней реструктуризайции произошла критическая ошибка Повторить обновления?
если жму нет то просто захлопывается. если жму да то сообщает что есть сотня активных сеансов 
в предприятие тоже не входит !!!!!!
BigShmax
1 — 18.10.12 — 10:41
во врем яобновления вылетел с ошибкой чтения какого то файла на сервере УПП 1.3 клиент серверная
shamashs
2 — 18.10.12 — 10:41
Администрирование — Активные пользователи, кто там?
sergey198
3 — 18.10.12 — 10:43
была тут тема, мне помогла..создал на сервере копию(архив) и скопировал из архива таблицы конфиги в рабочую..
BigShmax
4 — 18.10.12 — 10:43
(2) в консоли? толпа народа. но обновление я динамическое прводил зачем ему всех выгонять не понимаю
BigShmax
5 — 18.10.12 — 10:44
(3) БД 200 гигов скока я ща буду копии создавать
Stim
6 — 18.10.12 — 10:45
перезапусти сервер 1С
sergey198
7 — 18.10.12 — 10:45
(5) тебе нужно таблицы конфиги скопиравть..а не данных..
Cube
8 — 18.10.12 — 10:45
(4) А ты смелый… 
tdm
9 — 18.10.12 — 10:45
(4) над выгнать всех и запуститься монопольно — новые пользователи подключаться не смогут
tdm
10 — 18.10.12 — 10:46
(5)есть шанс все 200гигив потерять
BigShmax
11 — 18.10.12 — 10:46
(8) (9) не говорите ерунды. во первых есть фулбекап утренний во вторых демоническое зло но без него НЕЛЬЗЯ кругломсуточная работа и все такое.
ptiz
12 — 18.10.12 — 10:46
(5) А нет более-менее новой копии?
Если нет, то разворачивать архив.
tdm
13 — 18.10.12 — 10:47
(11) правильно расставляйте приоритеты! юзеров нафиг пока базу не восстановите
рискуете
shamashs
14 — 18.10.12 — 10:47
(4), Выгонять придется или откатывай обновление.
tdm
15 — 18.10.12 — 10:48
+(13) но это ваше дело конечно)
Starhan
16 — 18.10.12 — 10:48
(0) выгонять.
shamashs
17 — 18.10.12 — 10:48
У меня такое чувство что ктото завозил ИТС к клиенту и его по быстрому попросили упп обновить.
Starhan
18 — 18.10.12 — 10:49
(17) да довольно частая ошибка на больших базах еще и с распределенкой и т.п. Там вродь просто перезайти надо монопольно и все само вылечится
narayanan
19 — 18.10.12 — 10:49
shamashs
20 — 18.10.12 — 10:50
тогда пускай до ночи ждет, потом выгоняет.
y22-k
21 — 18.10.12 — 10:50
(0) попал…
Cube
22 — 18.10.12 — 10:50
(11) Демоническое обновление — зло, безо всяких «но».
А на счет «без него нельзя» — так это потому, что организовать работу не можешь…
tdm
23 — 18.10.12 — 10:52
(18) +1, все просто
(20) новые подключения к базе и сейчас не возможны, только те кто туда уже подключены могут работать) хз чего ТС ждет
ptiz
24 — 18.10.12 — 10:55
(13) +1
При любых подозрениях на сбои (программные или аппаратные), тут же всех выкидывать и делать архив.
Мы один раз попали, попробовав на ходу перестроить рейд-массив, когда один из дисков вылетел, теперь ученые.
Starhan
25 — 18.10.12 — 10:57
(19)
Надо сверху подписать: «Уронил базу. Скоро встреча с директором».
А снизу: А в кулаке у нее вазелин.
hhhh
26 — 18.10.12 — 11:00
(23) заявление пишет. И письмо будущему программисту.
BigShmax
27 — 18.10.12 — 11:02
(17) чувства в сторону, я знал что делал.
откинул всех ребутнул службу пробую войти в конфигуратор
Cube
28 — 18.10.12 — 11:03
(27) Видимость нулевая. Сбросил топливо, включил пассажирам рамштайн. Иду на посадку по приборам…
shamashs
29 — 18.10.12 — 11:03
(27) Прямо как пожарный, все вон иду вас спасать беру вину на себя! Ничо тс ничего страшного)
BigShmax
30 — 18.10.12 — 11:04
такое впечатление что 80% присутствующих потирают руки что база упала. для таких сообщаю что есть фулбекаб на 6 утра и каждый час дифф бекапы. потеря данных максимум 20-30 минут
shamashs
31 — 18.10.12 — 11:05
(30) Да нет сочувствууем, просто ситуация не критическая поэтому можем постебатся над несколько необычной реакцией ТС.
ptiz
32 — 18.10.12 — 11:06
Да мы просто наблюдаем.
(долил чая и взял еще печенек)
Sayshal
33 — 18.10.12 — 11:06
(19)Хватит!
Скай
34 — 18.10.12 — 11:06
Было такое, помог перезапуск монопольно…
Динамическое обновление зло… но такое заманчивое =)
BigShmax
35 — 18.10.12 — 11:07
неполучилось ограничить открытие новых сеансов после просто ребута службы . все равно всех пускает все лезут монопольно попасть не могу ребучу сервак
tdm
36 — 18.10.12 — 11:08
(30) да не потираем руки, было такое и не раз…все лишается монопольным запуском
просто тянуть время не стоит
Cube
37 — 18.10.12 — 11:08
(35) Про блокировку базы слыхал — не?))
tdm
38 — 18.10.12 — 11:09
(36) нафига? опять зайдут после ребута, если их много будут стучаться
tdm
39 — 18.10.12 — 11:09
(35) базу заблокировать и они сами отпадут
BigShmax
40 — 18.10.12 — 11:09
(38) ну вообщето запрет на новые сеансы раньше всегда помогал
tdm
41 — 18.10.12 — 11:09
(38) — > (35)
GenV
42 — 18.10.12 — 11:10
tdm
43 — 18.10.12 — 11:10
(40) имеенно, ребутить то зачем только ?))
BigShmax
44 — 18.10.12 — 11:12
как заблокировать базу от всех а. непомогает запрет на вход
BigShmax
45 — 18.10.12 — 11:12
не могу попасть монопольно
Cube
46 — 18.10.12 — 11:13
(44) Что есть «запрет на вход»?
Ставь блокировку базы с паролем, епта.
ptiz
47 — 18.10.12 — 11:14
(44) епт.. переименуй в консоли
BigShmax
48 — 18.10.12 — 11:14
(46) в консоли в свойствах бд ставлю глаку запретить новые сеансы. а Ваш метод где модно реализовать епта ? ну подскажите видно же что читать мне некогда
BigShmax
49 — 18.10.12 — 11:15
(47) спасиб дело
ptiz
50 — 18.10.12 — 11:16
вру…. не выйдет
BigShmax
51 — 18.10.12 — 11:16
вижу. не выходит
BigShmax
52 — 18.10.12 — 11:17
на скуле мож переименовать
ptiz
53 — 18.10.12 — 11:17
«ставлю глаку запретить новые сеансы»
должно работать
BigShmax
54 — 18.10.12 — 11:18
(53) типа мне скучно и я шучу? не срабатывает
Cube
55 — 18.10.12 — 11:18
(48) «Блокировка начала сеансов» — это и есть блокировка. Жди минут 5-15, вылетят все.
BigShmax
56 — 18.10.12 — 11:18
(55) он пускает даже новых
ptiz
57 — 18.10.12 — 11:18
(54) У тебя неправильная 1С
Cube
58 — 18.10.12 — 11:19
+(55) После установки блокировки можно из консоли всех повыкидывать (позавершать сеансы).
Cube
59 — 18.10.12 — 11:19
(56) Пароль блокировки задал?
BigShmax
60 — 18.10.12 — 11:21
сработало. кто нить подскажет какой ключ в ярлыке чтобы пустило
Cube
61 — 18.10.12 — 11:22
(60) /UC
BigShmax
62 — 18.10.12 — 11:23
сейчас такой
BigShmax
63 — 18.10.12 — 11:23
«C:Program Files (x86)1cv82common1cestart.exe»
Sammo
64 — 18.10.12 — 11:23
(60) /uc password
Cube
65 — 18.10.12 — 11:24
(63) Нужно так:
C:Program Files1cv828.2.15.318bin1cv8.exe /UC123456
BigShmax
66 — 18.10.12 — 11:25
пустил. думает
BigShmax
67 — 18.10.12 — 11:26
удаленный хост принудительно разорвал соединение пишет
BigShmax
68 — 18.10.12 — 11:29
ошибка сетевого доступа к севреру виндовс сокет удаленный хост принудительно разорвал существующее подключение line = 1033 file =
Cube
69 — 18.10.12 — 11:29
(68) Версия сервера и клиента одинаковая?
BigShmax
70 — 18.10.12 — 11:30
а с чего бы она поменялась
ptiz
71 — 18.10.12 — 11:30
Кэши чистил?
Cube
72 — 18.10.12 — 11:32
(70) В (65) версия клиента жестко указана и может не соответствовать последней установленной…
BigShmax
73 — 18.10.12 — 11:33
(72) см (63) там ключ прописал
Cube
74 — 18.10.12 — 11:35
(73) И че, работает?)) Раньше не работало так… Пойду проверю
BigShmax
75 — 18.10.12 — 11:35
беру ярлык жостко моей платформы — не получится восстанавливаю бекап
ptiz
76 — 18.10.12 — 11:36
(75) Давно бы параллельно запустил восстановление бекапа и оттуда таблицы конфигурации сейчас взял.
BigShmax
77 — 18.10.12 — 11:37
(76) я не знаю как это сделать
Cube
78 — 18.10.12 — 11:38
+(74) Ааааа)) Внатуре, работает!)) Наконец-то!)))
ptiz
79 — 18.10.12 — 11:38
ищи на инфостарте
Восстановление SQL базы 1С 8.2. рухнувшей во время сохранения конфигурации.
BigShmax
80 — 18.10.12 — 11:38
(79) проще 20 минут работы потерять чем ща 3 часа читать
ptiz
81 — 18.10.12 — 11:41
(80) нда…. там 3 всего-то 2 простеньких запроса по 1 строчке
ptiz
82 — 18.10.12 — 11:42
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С, и в случае успеха — прыгаем, как я от радости, что удалось оживить базу без каких-либо потерь информации.
ptiz
83 — 18.10.12 — 11:42
ну и с ConfigSave провернуть это же
Stim
84 — 18.10.12 — 11:43
не чокаясь.. за базу..
BigShmax
85 — 18.10.12 — 11:51
(82) (83) ту оставил на досуге потренируюсь сейчас восстанавлдиваю из архива 10 утра. слава sql серверу и его архивированию
Balonbl4
86 — 18.10.12 — 11:54
По 2й, за Скуль!
BigShmax
87 — 18.10.12 — 11:55
мне базу запустить и я 3 злпом могу
BigShmax
88 — 18.10.12 — 12:03
наверно три стакана надо че стопками организм травить
dmpl
89 — 18.10.12 — 12:10
(85) Славить будешь, когда восстановленная из бэкапа база заработает 
BigShmax
90 — 18.10.12 — 15:53
да нет тут проблем быть не могло восстановил со скулевого бекапа все работают
LamerSuper
91 — 18.10.12 — 16:41
Пару раз уже случалось увидеть такую надпись при обновлений конфигурации 1С. Причем не важно на какой платформе, что на 8.3.6, что на более новых 8.3.12. И что то мне кажется, что эта еще одна причуд системы, обычными методами в виде галочек, кнопочек и других атрибутов интерфейса, реализовано в ближайшее время не будет.
И мы остаемся с возможностью увидеть такое:
Чтобы не искать в следующий раз, запишу заметку на будущее.
С файловыми базами я не работаю, по этому и проблем как таковых для меня нет. Если возникают проблемы:
— Чистим кеш на локальном компьютере.
— Запускаем обработку chdbfl.exe для проверки конфигурации.
— Если не помогло, лезем в файлы базы. Находим обработку Tool_1CD.exe и с помощью ее редактируем файлы
— Есть метод описанный в статье https://infostart.ru/public/182889/
Фактически таблицы SQL базы и файловой не отличаются. По этому переходим к описанию действий на SQL:
— сперва смотрим, что есть в таблице dbo.configsave. Если что то там есть, удаляем : delete from configsave
— далее, если запустить profiler первое сообщение в 1С выводится после запроса select * from Config WHERE FileName = ‘commit’. Удаляем, чтобы сообщение не выводилось: delete from config where FileName = ‘commit’
— так же сообщение выводится после запроса select * from Config WHERE FileName = ‘dbStruFinal’. Удаляем тоже его: delete from config where FileName = ‘dbStruFinal’
Подводим итог:
Все изменения хранятся в таблице configsave. Если она пуста, а присутствует флаг для обновления конфигурации, данные копируются в таблицу config и следовательно затирают пустыми.
Список команд в SQL которые нужно выполнить последовательно,для того чтобы отменить обновление:
—delete from configsave
—delete from config where FileName = ‘commit’
—delete from config where FileName = ‘dynamicCommit’
—delete from config where FileName = ‘dbStruFinal’
Напоминаю, изложение данного материала не являются призывом к действию, а служит только для информации и ознакомления, которую читатель вправе сам выбирать, использовать или нет. Спасибо.
- Home
- /
- Knowledgebase
- /
- 1С
- /
- Ошибки
- /
- Разработка
- /
- Ошибка: При обновлении данн…
Ошибка: При обновлении данных после последней реструктуризации произошла критическая ошибка
Источник
Решение:
1. Создать копии таблиц Config и ConfigSave (на случай восстановления).
SELECT * INTO Config_copy FROM [Config]
;
SELECT * INTO ConfigSave_copy FROM [ConfigSave]2. Удалить все записи из таблицы ConfigSave (содержит обновление)
DELETE FROM [ConfigSave]3. Удалить три записи из таблицы Config (информация о незаконченном процессе обновления конфигурации)
DELETE FROM [Config] WHERE FileName IN ('commit','dbStruFinal','dynamicCommit')При обновлении конфигурации 1С произошел сбой, программа завершила свою работу по ошибке. Затем, при попытке зайты в конфигуратор, стало выдаваться предупреждение: «При обновлении данных после последней реструктуризации произошла критическая ошибка. Повторить обновление?». Если ответить «Нет», то программа просто завершает свою работу, в случае же положительного ответа выводится сообщение «Обнаружена незавершенная операция сохранения конфигурации. Для продолжения работы необходимо завершить операцию.» и программа также закрывается.
Еще ошибка может быть следующая: Нарушена целостность структуры конфигурации. В этом случае, в первую очередь, нужно попробовать почистить кэш 1С. Если не поможет, то читаем дальше.
Самый простой вариант решения данной задачи — восстановление из резервной копии. Но очень не хотелось терять последние введенные за день данные. Поэтому я решил разобраться в вопросе более досканально.
Выяснилось, что все измененные объекты конфигурации программа хранит в таблице configsave. Но в моем случае табличка оказалась пустая. При обновлении конфигурации программа снача копирует все изменения из таблицы configsave в таблицу config, затем очищает первую.
Если имеется база данных с идентичной конфигурацией, то можно полностью перенести из нее таблицу config в испорченную базу. Либо можно удалить все зафиксированные изменения. В этом случае алгоритм восстановления примерно следующий:
- Если в таблице configsave есть данные, то таблицу нужно очистить: delete from configsave
- delete from config where FileName = ‘commit’
- delete from config where FileName = ‘dynamicCommit’
- delete from config where FileName = ‘dbStruFinal’
Добавлено 03.10.2019:
Если то, что описано выше не помогло, то можно перенести конфигурацию с рабочей копии базы (если таковая имеется). Например, если у вас имеется копия базы с такой же конфигурацией, но за вчерашнее число и не хочется терять введенные за сегодня данные.
Для этого выполним следующий запрос:
USE [ИмяРабочейБазы]
DELETE FROM [DBO].[ConfigSave]
DELETE FROM [DBO].[Config]
INSERT INTO [ИмяРабочейБазы].[Dbo].[Config] SELECT * FROM [ИмяКопииБазы].[Dbo].[Config]
GO