Неочевидный баг Истории данных, убивающий rphost
База данных - Администрирование СУБД
После очередного обновления у нас повалился шквал заявок. Пользователи не могли работать. Сеансы завершались. Что коллеги только не пробовали, даже перешли на платформу 8.3.23.
В итоге начали глушить регламентные задания и нашли причину. Накануне трагедии была добавлена внешняя обработка с регламентными заданиями, и одно из этих заданий запускало создание версий для «Истории данных»
Код задания:
ИсторияДанных.ОбновитьИсторию();
На первый взгляд ломаться нечему… Но, когда регламент был выключен, все работало как прежде, правда, не создавались версии.
Для начала была создана обработка с одной единственной кнопкой, выполняющей код, написанный выше. При запуске вручную выпадала ошибка:
Текст ошибки:
«На сервере 1С:Предприятия произошла неисправимая ошибка. Приложение будет закрыто»
Дальше стало интереснее. Коллега решил проверить, рушится на всех объектах или на каком-то определенном. История у нас в базе, в которой это происходило, велась только по документам.
Он написал небольшой цикл, в котором оббегал Метаданные.Документы и добавлял в массив документы, запуская обновление истории данных по выбранным типам документов.
Синтаксис:
ОбновитьИсторию(<ВключитьМетаданные>, <ИсключитьМетаданные>, <ВыполнитьОбработкуПослеЗаписиВерсий>, <АвтоУдалениеИзОбработкиПослеЗаписиВерсий>)
Таким образом был выявлен один из типов документов, на котором происходило «Крушение». Это основной документ для той конфигурации, в которой запускался регламент.
Дальше коллега попытался запустить обновление, подавая ссылку одного документ данного типа. Обновление по ссылке одного документа работало без проблем.
И все бы ничего, но именно по данному документу и еще по одному История данных была включена в самой конфигурации более полугода назад, мало того, по данному документу было включено «Обновление истории данных сразу после записи».
Другие же документы, по которым проходило создание версий, были включены программно перед тем, как был создан регламент, убивающий rphost.
Дальше за проблему взялся я и полез в SQL. Я решил пройтись по таблицам Истории данных и посмотреть на «странности, которые бросятся в глаза»
Первым делом нужно было определить [_MetadataId] у документа, который приводит к катастрофе, сделать это было легко. Документ у меня был включен в конфигураторе, значит, мне его нужно было выключить программно и посмотреть в таблице [_DataHistorySettings] на [_MetadataId] у новой строки. Для программного отключения я использовал свою обработку Настройка состава "Истории данных"
Дальше я полез в таблицу [_DataHistoryMetadata], если кратко, в данной таблице хранится структура объекта, и при изменении в конфигураторе данного объекта создается новая запись с новым значением версии метаданных.
Хм… А почему у некого поля _Fld312 значение NULL по данному документу? Ранее я уже видел поля _Fldxxx в данной таблице, но в других конфигурациях, и стал догадываться, что это общий реквизит.
Далее я запустил первую попавшуюся под руку обработку по получению соответствия метаданных с наименованием в СУБД и вуаля.
Fld312 -> ОбщийРеквизит.ОбластьДанныхОсновныеДанные
Данную базу у нас обновляют непосредственно создатели конфигурации и, видимо, несколько месяцев назад они добавили новый общий реквизит.
Как будем лечить?
Вариант 1. Тушить пожар.
В обновлении истории подать исключенные метаданные.
Синтаксис:
ОбновитьИсторию(<ВключитьМетаданные>, <ИсключитьМетаданные>, <ВыполнитьОбработкуПослеЗаписиВерсий>, <АвтоУдалениеИзОбработкиПослеЗаписиВерсий>)
Вариант 2. Лечить проблему вопреки лозунгам фирмы 1С не лазить в SQL.
Я выбрал этот вариант.
Скрипт SQL:
update [Моя_БД].[dbo].[_DataHistoryMetadata] set _Fld312 = 0 where _Fld312 is NULL
Итог:
После этого регламент стал работать отлично.
Ошибка была отправлена в 1С.
Выводы:
1) Судя по всему, в фирме 1С не предусмотрели взаимодействие с общими реквизитами, в связи с чем если вы вдруг для каких-то «странных целей» добавите общие реквизиты, не забудьте прописать значение по умолчанию в SQL, иначе словите убийственный баг.
2) Не слушайте вендора, призывающего не лазить в SQL.
На этом статью заканчиваю. Надеюсь, сэкономил чье-то время на поиск подобной ситуации.
Полезные статьи по данной теме:
Версионирование объектов VS История данных
Вступайте в нашу телеграмм-группу Инфостарт
ИсторияДанных rphost Баг ОбновитьИсторию Метаданные DataHistorySettings DataHistoryMetadata MetadataId общие реквизиты
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
HighLoad оптимизация Администрирование СУБД Разработчик 1С:Предприятие 8 1С:ERP Управление предприятием 2 Бухгалтерский учет Бесплатно (free)
После миграции с MS SQL на PostgreSQL закрытие месяца в 1С:ERP стало идти 8 часов вместо 12 минут. Рассказываем, как мы нашли причину в оценке Hash Join, которую планировщик завышал в миллионы раз, и как исправили её так, что проблемный запрос теперь выполняется за 18 секунд вместо часа.
19.10.2026 959 Tantor 0
Администрирование СУБД Сервера Системный администратор Разработчик 1С:Предприятие 8 Россия Бесплатно (free)
Примеры скриптов для работы с автономным сервером (ibsrv).
09.10.2026 1071 hexhoc 6
Администрирование СУБД HighLoad оптимизация Разработчик 1С:Предприятие 8 1С:ERP Управление предприятием 2 Россия Бесплатно (free)
Большинство материалов о компрессии в PostgreSQL отвечают на вопрос «во сколько раз удалось уменьшить базу». Мы предлагаем посмотреть на проблему с другой стороны — какой ценой достигается эта экономия? В статье разбираем архитектурные компромиссы различных подходов к компрессии страниц, объясняем, почему при разработке CSM в Tantor Postgres отказались от погони за максимальным коэффициентом сжатия, и показываем результаты нагрузочных испытаний на реальных базах 1С.
01.10.2026 1457 Tantor 6
DevOps и автоматизация разработки Администрирование СУБД Групповая разработка (Git, хранилище) Разработчик 1С 8.3 Абонемент ($m)
В корпоративных инсталляциях «1С:Предприятие 8.3» под управлением PostgreSQL всё чаще проявляются архитектурные пределы масштабирования: рост числа пользователей, обязательная маркировка, плотный поток API-интеграций и высокая стоимость простоя. Вводная часть цикла разбирает ключевые факторы современной эксплуатационной нагрузки и формирует инженерную методологию эволюционной модернизации без остановки продуктивного контура. Материал основан на практическом кейсе «Торговый контур» и показывает, как определить целевые метрики (p95, MTTR, APDEX), выстроить наблюдаемость, стабилизировать работу кластера и подготовить инфраструктуру к дальнейшему масштабированию. Публикация задаёт фундамент для последующих частей, посвящённых телеметрии, оптимизации PostgreSQL, CI/CD и архитектурному росту.
1 стартмани
10.09.2026 1526 Ninel_S 0
HighLoad оптимизация Администрирование СУБД Разработчик 1С:Предприятие 8 1С:ERP Управление предприятием 2 Бесплатно (free)
В рамках 18 релиза СУБД Tantor Postgres мы рассказывали об оптимизациях, которые помогают планировщику сделать более точный выбор между Nested Loop и Hash Join. В следующем релизе у нас планируются оптимизации, которые позволят ускорить выполнение как Nested Loop, так и Hash Join. Сегодня мы расскажем об одном из таких методов - фильтре Блума.
31.08.2026 6122 Tantor 3
Администрирование СУБД Системный администратор Разработчик 1С 8.3 Бесплатно (free)
Мы подготовили для сообщества Infostart.ru практическое занятие, в котором каждый желающий сможет: научиться собирать реальные данные о процессах кластера 1С; выявлять «перестарков» — процессы старше периода и без соединений; выполнять безопасный перезапуск (с dry-run и подтверждением); настраивать автоматическую проверку через systemd на Linux; отправлять уведомления (Telegram, почта) при обнаружении проблем; работать с логами, ротацией, профилями кластеров и конфигурацией; развернуть полноценный учебный проект AdminClusterMonitor у себя в тестовой среде.
30.08.2026 1736 Ninel_S 2
Администрирование СУБД Системный администратор 1С:Предприятие 8 Бесплатно (free)
На infostart.ru вышел разбор Ивана Недомолкова «Сервер 1С падает: настройка сбора дампов (logcfg.xml), лимиты памяти и передача дампа в поддержку» - это хорошая инструкция, как ловить и разбирать падение rphost постфактум: logcfg.xml, procdump, анализ дампа. Но там нет ответа на вопрос «а почему кластер вообще прибил процесс сам, ещё до всякого краша». Мы дополняем разбор тремя сводными таблицами лимитов памяти и автомасштабирования кластера - и заодно фиксируем, чем в этой части лицензия ПРОФ урезана относительно КОРП.
12.08.2026 2390 Ninel_S 5
Администрирование СУБД Системный администратор Разработчик Бесплатно (free)
5,5 тысячи пользователей в единой базе 1С, розница в режиме 24/7 и SLA 99,98% – в таких условиях любая авария быстро превращается в очереди на кассах, потерю денег и давление со стороны бизнеса. Показываем, как выстроить процесс аварийно-восстановительных работ: от первых алертов и базового скрининга системы до подключения команды, проверки гипотез и дебрифа после инцидента. Разбираем, как метрики, дашборды, техжурнал, Zabbix, Prometheus, Grafana, Telegram-боты и скрипты помогают не гадать, а быстро находить причину проблемы. На реальных авариях объясняем, почему «быстро» не должно означать «рискованно», как работа над ошибками снижает панику и почему каждая авария может сделать систему надежнее.
11.08.2026 3409 jul.dolganova 9
Тех журнал снимали, но ничего там не увидели.
12:30.527007-59502998,EXCPCNTX,1,SrcName=CONN,process=1cv8c,OSThread=14668,ClientID=8,Txt=Outgoing connection closed
12:30.527008-0,EXCP,1,process=1cv8c,OSThread=14668,Exception=81029657-3fe6-4cd6-80c0-36de78fe6657,Descr='src\rtrsrvc\src\RemoteInterfaceImpl.cpp(850):
81029657-3fe6-4cd6-80c0-36de78fe6657: server_addr=ххххх descr=10054(0x00002746): Удаленный хост принудительно разорвал существующее подключение. line=1610 file=src\rtrsrvc\src\DataExchangeTcpClientImpl.cpp'
12:30.980002-0,EXCP,2,process=1cv8c,OSThread=3680,Exception=e0417abc-63b4-461b-b1b6-01d2d2b0cca5,Descr='src\mngui\src\ExceptionWriterUIImpl.cpp(717), shown to the user:
e0417abc-63b4-461b-b1b6-01d2d2b0cca5: На сервере 1С:Предприятия произошла неисправимая ошибка. Приложение будет закрыто'
Информацию об ошибке отправил сегодня с утра.
Присвоенный номер ошибки HL-747523
Ссылка:
Здесь есть упоминание этой же ошибки: "Если конфигурация работает под платформой 8.3.21 и в конфигурации есть расширения, установленные до перехода на платформу 8.3.21, то может оказаться что установка рассматриваемого модуля расширения при попытке запуска после установки может дать
ошибку SDBL:\nВ схеме базы данных нет таблицы с именем DataHistorySettingsExt. В этом случае следует добавлять расширение под версией платформы 1с 8.3.20."
В моем случае базу открыть в версии 8.3.20 не представляется возможным, конфигуратор просит версию не ниже 8.3.21.
- что происходило при "убийственной ошибки" в технологическом журнале?
- отправляли ли вы информацию об ошибке вендору? можете скинуть номер ошибки с bugboard 1C ?
Тех журнал снимали, но ничего там не увидели.
12:30.527007-59502998,EXCPCNTX,1,SrcName=CONN,process=1cv8c,OSThread=14668,ClientID=8,Txt=Outgoing connection closed
12:30.527008-0,EXCP,1,process=1cv8c,OSThread=14668,Exception=81029657-3fe6-4cd6-80c0-36de78fe6657,Descr='src\rtrsrvc\src\RemoteInterfaceImpl.cpp(850):
81029657-3fe6-4cd6-80c0-36de78fe6657: server_addr=ххххх descr=10054(0x00002746): Удаленный хост принудительно разорвал существующее подключение. line=1610 file=src\rtrsrvc\src\DataExchangeTcpClientImpl.cpp'
12:30.980002-0,EXCP,2,process=1cv8c,OSThread=3680,Exception=e0417abc-63b4-461b-b1b6-01d2d2b0cca5,Descr='src\mngui\src\ExceptionWriterUIImpl.cpp(717), shown to the user:
e0417abc-63b4-461b-b1b6-01d2d2b0cca5: На сервере 1С:Предприятия произошла неисправимая ошибка. Приложение будет закрыто'
Информацию об ошибке отправил сегодня с утра.
Присвоенный номер ошибки HL-747523
Ссылка:
С другой стороны, как показывает многочисленная практика, 1С не несет никакой ответственности и в случае, если Вы в базу не лазите. Вот, например, с историей. Добавили общий реквизит - все сломалось. Понесла 1С ответственность за Ваш простой? Нет. Можно ли ей что предъявить? Что-то сомневаюсь.
Я часто на собеседовании спрашиваю: -что делать если срочно нужно почистить данные в регистре сведений с несколькими миллионами записей? При условии, что база скульная.
60-70% в sql не лезут.
РегистрыСведений.МойРегистр.СоздатьНаборЗаписей().Записать();ЗЫ: А вообще, скуль, ежу понятно, быстрее работает. Но если регистр сведений независимый, у него нет таблицы изменений, он никуда не ездит и ни с чем не синхронизируется, то особой разницы по времени между транкейтом и записью пустого набора нет. Да, скуль будет писать все удаленные записи в лог, но лог пишется достаточно быстро. И тут в каждом конкретном случае надо думать, как стоит делать.
Первоначально спорные вещи сделаю на тестовой базе.
На практике было много вещей которые можно было сделать только на SQL в отведенные временные рамки.
П.С. Со мной как-то работал коллега которому давали ночь на переход с бухии 2 на бухию 3. При этом бухия 2 была сильно перепилена, в ней было очень много НСИ, документов и когда он переходил стандартными средствами укладывался минимум в 2 дня. Он несколько месяцев потратил чтобы нарисовать скрипты повторяющие то что делает 1с при переходе, вплоть до создания НСИ, документов и идентификаторов.
Потом он запустил этот скрипт и уложился в 1-2 часа.
Я до сих пор поражаюсь той работе которую он проделал.
Такие кейсы на Infostart'e не покажут.
У "нас" в одной конторе (три работы назад) был ежегодный переезд с
(0) Статья крайне опасна (особенно для начинающих), т.к.:
1. Подобное использование нарушает ЛС
2. Полностью не учитывается, что в событиях объекта может производится дополнительная обработка при постановке/снятии пометки удаления
Проще говоря: чревато разрушением данных
Возможно причина "бага" в п.2 из выводов? При обмене для ускорения реструктуризации не применялись методы подобные этому? =>
(Яндексим "Метод быстрой реструктуризации больших таблиц (10 миллионов записей и более) через SQL Server Managment Studio").
не, причина не в этом. У нас базу на которой мы словили поддерживает фирма которая и разработала конфигурацию, они дальше 1с не лазят.
В принципе этот баг легко повторить. Я думаю даже с расширением можно повторить, а значит можно уронить облака 1с например.
С БСП шной реализацией все т.к. данные лежат в РС.
1. В старом расширении включил режим совместимости 8.3.20;
2. Cоздал справочник;
3. Включил у него Историю данных.
После этих действий справочник открылся нормально, до этого выполнял только пункт 2 и программа выдавала ту же ошибку.
Все это на платформе 8.3.23.1912
должна появится надпись при реструктуризации содержащая "новая версия"
2. удалить расширение и добавить, при добавлении должны создаться таблицы по DataHistory.... , 4 штуки
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 1970736
Создание 08.11.23 08:00
Обновление 08.11.23 08:00
Просмотры 16291
Загрузки 0
Рейтинг
74
Комментарии 49
Код открыт Да
Рубрики Администрирование СУБД
Кому
Системный администратор
,
Разработчик
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация Универсальные
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
