этот регистр «слепой» — непонятно действительно ли данные содержат дубли и что такое в данном случае дубли
в этом регистре значительное количество записей — более 7000
Кроме того, нет возможности пометить на удаление или удалить такие записи непосредственно из регистра
Для прояснения ситуации направила разработчику запрос:
Что программа понимает как дубли? Если сочетание Тип владельца + Наименование, показанное в поле Владелец данных, то почему позволяется записывать такие данные?
5,5 тысячи пользователей в единой базе 1С, розница в режиме 24/7 и SLA 99,98% – в таких условиях любая авария быстро превращается в очереди на кассах, потерю денег и давление со стороны бизнеса. Показываем, как выстроить процесс аварийно-восстановительных работ: от первых алертов и базового скрининга системы до подключения команды, проверки гипотез и дебрифа после инцидента. Разбираем, как метрики, дашборды, техжурнал, Zabbix, Prometheus, Grafana, Telegram-боты и скрипты помогают не гадать, а быстро находить причину проблемы. На реальных авариях объясняем, почему «быстро» не должно означать «рискованно», как работа над ошибками снижает панику и почему каждая авария может сделать систему надежнее.
Пароль пользователя СУБД лежит в 1CV8Clst.lst обратимо: кто читает папку srvinfo - достаёт пароли SQL всех баз кластера, минуя права 1С. Обработка показывает, у каких баз пароль извлекается, помечает слабые и выдаёт план защиты. К СУБД не подключается, ничего не пишет - только читает файл.
Прогнал набор диагностических скриптов на двух рабочих базах: боевой с 580 сеансами и малонагруженной. Разбираю пять находок: статистика 97-дневной давности, 598 запросов со сканами, журнал транзакций в 73 % от данных, tempdb в один файл и 81 % ожиданий на параллелизме, который чинить не надо. Плюс три грабли, из-за которых самописный диагностический скрипт падает на чужом сервере. Семь рабочих скриптов внутри, копируются в SSMS как есть.
Журнал регистрации на нагруженной базе перестаёт открываться: файлы растут на гигабайты в день, просмотр виснет, история недоступна. Рассказываю, как мы вынесли журнал трёх продуктивных баз в ClickHouse: 35 млрд событий, поиск всех ошибок за сутки — 0,11 секунды, привычная форма журнала для пользователей и падение числа ошибок в проде в 23 раза за полгода. Архитектура, схема таблицы, грабли интеграции и все цифры с прода.
База 1С:ERP размером 646 Гб, полное маскирование за 5 часов - без создания промежуточной незащищенной копии. Разбираем бесплатный pg_anon на сквозном примере с реального продуктива.
Если вы работаете с 1С на PostgreSQL и жалуетесь на тормоза — скорее всего, дело в join predicate pushdown, которого в стандартном PostgreSQL нет. В MS SQL Server этот механизм работает «из коробки», и при миграции именно запросы к виртуальным таблицам 1С бьют по производительности сильнее всего. В этой статье — реальный кейс от Postgres Professional с разбором плана выполнения, ручным экспериментом и доработкой планировщика СУБД, которая ускорила запросы от 22 до 54 000 раз.
Вышел релиз СУБД Tantor Postgres 18, и мы хотим рассказать о его новых возможностях для работы с приложениями на платформе "1С:Предприятие". В обзоре разберем улучшения планировщика, по традиции коснемся работы временных таблиц и не обойдем вниманием вспомогательные утилиты, которые упрощают поиск и диагностику проблем в высоконагруженных системах. За каждым пунктом - реальные запросы 1С, реальные рабочие базы и сотни часов тестирования!
База 1С за несколько лет эксплуатации разрослась, - стала большой, медленно работает, требует много места и времени для копирования и прочего обслуживания. Нужна ли обязательно свертка или можно обойтись более «мягкими» средствами. Делюсь своим опытном как для новых конфигураций, так и для старых УПП, УТ 10…
Система обеспечивает контроль уникальности записей, хранящихся в регистре сведений. Таким образом, в регистре сведений не может находиться двух одинаковых записей. Одинаковыми считаются записи, у которых совпадает ключ записи. Ключ записи формируется системой автоматически, на основании значений, содержащихся в полях записи, и зависит от вида регистра сведений.
В общем случае в формировании ключа записи будут участвовать значения регистратора, периода и значения измерений. Таким образом, например, в непериодическом регистре сведений Цены товаров с независимым режимом записи не может существовать двух записей о розничной цене конфет ассорти. Точно так же, как в периодическом регистре сведений Цены товаров, подчиненном регистратору, не может существовать двух записей о розничной цене конфет ассорти, внесенных одной и той же датой, одним и тем же документом Изменение цен товаров.
Источник:
Для файловой базы одна из причин, например - это "битые" записи во внутренней таблице. Буквально вчера столкнулся с такой же ситуацией при обновлении 1С:Розница в отношении РС "ФискальныеОперации". При тестировании на логическую целостность платформа выдала сообщение, что файл базы данных поврежден. В результате тестирования утилитой chdbfl в регистре было "потеряно" 4 записи, после чего обновление прошло без проблем.
Всем добрый день. в моем случае тестирование и исправление не выявляло ошибок. Поиск дублей не давал результатов. Обращаю внимание, что публикация про регистр сведений ДвоичныеДанныеФайлов. а он весьма специфичен!
(4) Добрый день. Если ошибка по регистру Двоичные данные файлов, то, к сожалению, я не нашла вариантов, кроме изменения конфигурации. С другими регистрами легче. Там можно найти дубли и сделать их НЕ дублями. Может помочь обработка из публикации .
(7) Мария, огромное вас спасибо, всё получилось!!!
Перенесла файлы на диск (и клиенту надеюсь хорошо - значительно меньше теперь база весит и регистр стал пустым), после этого выполнила сжатие таблиц ИБ и ошибка исчезла.
Добрый день!
Натолкнулся на такую же ошибку, неделю назад, при обновлении (правда совсем "седой" базы релиза 64). Не помог ни один вариант, ни с форумов, ни с вашей статьи :)
Решение получилось "не научным "тыком"" - запустил обновление с платформы 2018 года (8.12....) - обновление прошло абсолютно в штатном режиме (База вскрытая)
Вдруг кому-то тоже поможет)
Добрый день!
Спасибо за идею снять флаг объединения с этого объекта, это действительно помогло. До этого при возникновении такой ошибки я просто очищал весь регистр, что в принципе не совсем красиво.
Но вот что я при этом увидел в подробностях объединения.
Оно фактически Измерение Файл удаляет и одновременно создает новое измерение с тем же именем. Тем самым это измерение у всех записей регистра становится пустое, поэтому после объединения они и оказываются не уникальными. Поэтому поиск дублирующих записей ДО обновления в этой ситуации не имеет смысла.
Почему оно так делает - непонятно, могу только уточнить, что подобная ошибка у меня возникает только при обновлениях очень древних баз, некогда сконвертированных еще из БП 2.0
Судя по всему теперь флаг объединения с этого регистра придется снимать при каждом очередном обновлении.
Чтобы эта проблема не повторялось для двоичных данных нужно перед тем, как изменять ОпределяемыйТип нужно убрать данные этого типа из регистра сведений ДвоичныеДанные, предварительно переместив их в другой регистр.
&НаСервереБезКонтекста
Процедура УстановитьДвоичныеДанныеНаСервере(Файл)
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ДвоичныеДанныеФайлов.Файл КАК Файл,
| ДвоичныеДанныеФайлов.ДвоичныеДанныеФайла КАК ДвоичныеДанныеФайла
|ИЗ
| РегистрСведений.ДвоичныеДанныеФайлов КАК ДвоичныеДанныеФайлов
|ГДЕ
| ДвоичныеДанныеФайлов.Файл = &Файл";
Запрос.УстановитьПараметр("Файл", Файл);
РезультатЗапроса = Запрос.Выполнить();
Выборка = РезультатЗапроса.Выбрать();
Пока Выборка.Следующий() Цикл
МенеджерЗаписи = РегистрыСведений.Заказ_ДвоичныеДанныеФайлов.СоздатьМенеджерЗаписи();
МенеджерЗаписи.Файл = Файл;
МенеджерЗаписи.ДвоичныеДанныеФайла = Выборка.ДвоичныеДанныеФайла;
МенеджерЗаписи.Записать();
КонецЦикла;
КонецПроцедуры
Показать
Где Файл это элемент справочника удаляемого типа.
Потом удалить:
&НаСервереБезКонтекста
Процедура УдалитьДвоичныеДанныеНаСервере()
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ДвоичныеДанныеФайлов.Файл КАК Файл,
| ДвоичныеДанныеФайлов.ДвоичныеДанныеФайла КАК ДвоичныеДанныеФайла
|ИЗ
| РегистрСведений.ДвоичныеДанныеФайлов КАК ДвоичныеДанныеФайлов
|ГДЕ
| ТИПЗНАЧЕНИЯ(ДвоичныеДанныеФайлов.Файл) = ТИП(Справочник.бит_мат_ЗаказНаТехникуПрисоединенныеФайлы)";
РезультатЗапроса = Запрос.Выполнить();
Выборка = РезультатЗапроса.Выбрать();
Пока Выборка.Следующий() Цикл
НаборЗаписей = РегистрыСведений.ДвоичныеДанныеФайлов.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.Файл.Установить(Выборка.Файл);
НаборЗаписей.Записать();
КонецЦикла;
КонецПроцедуры
Натолкнулся при обновлении УТ до версии УТ 11.4.13.47. Проблема была с регистрами "двоичные данные файлов" и "файлы в рабочем каталоге". Решил по другому. Сделал выгрузку этих регистров в файл с помощью "Универсальной выгрузки загрузки в XML" из комплекта обработок ИТС. Очистил регистры, завершил обновление, загрузил данные обратно с помощью той же обработки.
Оставлю это здесь, может кому поможет. Скорее всего ошибка не в дублях, а в том, что вы добавляли в определяемые типы ПрисоединенныйФайлОбъект и др. свои объекты, проверьте
(16)
Хорошая мысль. Возможно при обновлении в определяемом типе ПрисоединенныйФайл или ВладелецПрисоединенныхФайлов затираются добавленные самостоятельно типы (если делали присоединяемые файлы к справочнику или документу).
Так как регистр сведений ДвоичныеДанныеФайлов (или НаличиеФайлов) имеет измерение Файл (или ОбъектСФайлами) измененного определяемого типа, то содержимое некоторых измерений затрется (например, тех самых самостоятельно добавленных владельцев присоединенных файлов). Соответственно будут образовываться дубли с одинаковыми "пустыми" измерениями в результате обновления, которых не было до.
(20) user708045_vantaqa: (5) Добрый день. Подскажите пожалуйста, а что конкретно вы изменяли в конфигурации?
РЕШЕНИЕ (подробно - см публикацию):
Для регистра сведений ДвоичныеДанныеФайлов установить режим Редактируется с сохранением поддержки
Добавить Ресурс (добавила Ресурс1, строка)
У меня также возникла проблема с этим регистром сведений при обновлении древней конфигурации УТ. Я решил проблему стандартными средствами УТ.
1. В настройках УТ изменил способ хранения файлом на тома диска. Перенес все файлы в том на диске стандартной процедурой УТ.
2. Очистил этот регистр сведений.
3. Обновил конфигурацию.
4. Перенес все файлы из томов обратно в информационную базу и вернул настройки УТ обратно.
подобная ошибка возникла при обновлении Бухгалтерии предприятия на 3.0.127.49
запросом не удалось найти дубли
обработкой //infostart.ru/public/538465/ тоже не нашлось дублей
добавлял измерение, затем ресурс, тоже не помогло
пришлось очистить регистр, обновить, затем восстановить записи
Была похожая проблема.
Обновлял базу. Вроде должна быть типовой, но сразу пошло в сравнение и показало отличие объектов, причем там справки, еще что-то несущественное и если посмотреть в сравнении - то в реальности не отличается. ну и .. с ним думаю, ставлю на поддержку, а мне вот такой же привет про регистр двоичных данных и про записи с измерениями одинаковыми. Ну и понятное дело - не ставит на поддержку.
в общем помогло вот что. включил хранение томов снаружи базы. выгрузил все туда, и осталось две записи. их удалил с помощью ИР, после чего загрузил данные обратно и отключил хранение снаружи, вот после этого прошло нормально. а никакое ТИИ и лечение не давали ничего
Мне помогло лишь манипулирование с типом ОпределяемыйТип. Я обновлял нетиповую конфу, и в этот тип, который у меня уже ранее редактировался, добавлялась ссылка на какой-то новый справочник.
Что я сделал? Снял галку в сопоставлении с обновлений этих типов (кажется четыре разных было, два со словом ПрисоединяемыеФайлы и два со словом ВладелецПрисоединяемыхФайлов).
Нажал бочку после этого. Отлично, кнопка "Применить" появилась. Нажал бочку.
А уже потом вручную добавил те типы ссылок в этот определяемый тип, которые изначально нужно было.
И всё прекрасно работает.
(35) ArtyomPotapov, спасибо большое, как раз мой случай. Не было дублей по запросу, ни пустых записей, ни битых ссылок, а обновление упорно не ставилось по причине неуникальных записей регистра сведений. Убрать галочку в окне сравнения и объединения помогло, так как именно в определяемый тип были внесены изменения предыдущим программистом.
добавлю. в ERP тоже меняли определяемые типы. и вот периодически вылазят те же проблемы по двум РС НаличиеФайлов и Рс Сведения о файлах.
спасаемся выгрузкой и восстановлением данных из базы по этим регистрам.
почему-то не помогает снятие галок в сравнении и объединении...