Ошибка при реструктуризации базы |
Я |
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 гб, и не настаиваю что всем это поможет, но в друг кому то пригодится .
Автор eXtremer, 22 окт 2019, 09:43
0 Пользователей и 1 гость просматривают эту тему.
Добрый день,
При реструктуризации базы данных 1С всплывает ошибка: server_addr=tcp://1c:1560 descr=10054(0x00002746): An existing connection was forcibly closed by the remote host. line=1584 file=srcDataExchangeTcpClientImpl.cpp
В чем может быть проблема?
1. 1С сервер и SQL стоят вместе на одной машине (платформа 8.3.10.2375).
2. Метод подключения «Shared memory».
Спасибо.
Запускаете прям на сервере или на пользовательской машинке? Если второе то попробуйте запуск на прямую с сервера.
Цитата: Chgdz от 22 окт 2019, 10:27
Запускаете прям на сервере или на пользовательской машинке? Если второе то попробуйте запуск на прямую с сервера.
На пользовательской машинке. Да, тоже думал прям на серваке запустить. Через пару часов попробую и отпишусь.
Добавлено: 22 окт 2019, 13:55
Запустил на сервере, ошибка идентична.
Ошибка обращения к серверу 1С:Предприятия.
по причине:
server_addr=tcp://1c:1560 descr=10054(0x00002746): An existing connection was forcibly closed by the remote host. line=1584 file=srcDataExchangeTcpClientImpl.cpp
Цитата: eXtremer от 22 окт 2019, 10:47
Цитата: Chgdz от 22 окт 2019, 10:27
Запускаете прям на сервере или на пользовательской машинке? Если второе то попробуйте запуск на прямую с сервера.На пользовательской машинке. Да, тоже думал прям на серваке запустить. Через пару часов попробую и отпишусь.
Добавлено: 22 окт 2019, 13:55
Запустил на сервере, ошибка идентична.
Ошибка обращения к серверу 1С:Предприятия.
по причине:
server_addr=tcp://1c:1560 descr=10054(0x00002746): An existing connection was forcibly closed by the remote host. line=1584 file=srcDataExchangeTcpClientImpl.cpp
Вопрос, у вас стоит ограничение на кластере 1С на серваке? Если да то увеличивайте/снимайте. Следующее это сетевые настройки, отключите IPv6. Посмотрите подробнее Windows логи, там могут быть аварийные завершения rphost со своей расшифровкой.
Цитата: Chgdz от 23 окт 2019, 04:04
Вопрос, у вас стоит ограничение на кластере 1С на серваке? Если да то увеличивайте/снимайте. Следующее это сетевые настройки, отключите IPv6. Посмотрите подробнее Windows логи, там могут быть аварийные завершения rphost со своей расшифровкой.
Если вы про ограничения в скрине, то тогда да, было 600, сейчас установил безлимит, только вечером смогу потестить.
По поводу сетевых настройках, платформа 1С и SQL установлены на одной машине, по сети вроде ничего не бегает.
Добавлено: 23 окт 2019, 20:01
Когда проводил реструктуризацию я не следил за процессом, видел только ошибку. Сегодня смотрел весь процесс, чтобы увидеть что именно происходит. Дважды проводил ту же операцию чтобы быть уверенными в оба раза процесс останавливается на «РегистрБухгалтерии.Основной 6489600», пару секунд ЦПУ грузится и через 30 сек. выскакивает ошибка: server_addr=tcp://1c:1560 descr=10054(0x00002746): An existing connection was forcibly closed by the remote host. line=1584 file=srcDataExchangeTcpClientImpl.cpp
Теги:
- Форум 1С
-
►
Форум 1С — ПРЕДПРИЯТИЕ 8.0 8.1 8.2 8.3 8.4 -
►
Установка и администрирование 1С Предприятие 8 -
►
Ошибка реструктуризации базы данных 1С: server_addr=tcp://1C:1560 descr=10054(0x00002746)
Похожие темы (5)
Поиск
При обновлении данных, после последней реструктуризации, произошла критическая ошибка. Повторить обновление?
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’
Напоминаю, изложение данного материала не являются призывом к действию, а служит только для информации и ознакомления, которую читатель вправе сам выбирать, использовать или нет. Спасибо.
Нам всем знакомо, как долго может идти обновление: это может занимать несколько часов, а в некоторых случаях – даже
несколько дней.
Однако, его можно заметно ускорить. А для этого нужно немного погрузиться в детали и поговорить о реструктуризации 
Когда в 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С тормозит, а вы ничего не делаете» – это и раньше было нехорошо, а теперь и вовсе непозволительная роскошь.
При обновлении конфигурации 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