После переход на новый сервер windows 2025, sql 2025 база УНФ стала очень долго выгружаться в дт. Заметил что застревает на простейшем запросе
SELECT _Fld12908_TYPE, _Fld12908_RTRef, _Fld12908_RRRef, _Fld12909, _Fld12910, _Fld12911_TYPE, _Fld12911_RTRef, _Fld12911_RRRef, _Fld12912, _Fld12913, _Fld12914RRef, _Fld12915, _Fld12916, _Fld12917, _Fld12918, _Fld12919, _Fld12920, _Fld12921, _Fld12922, _Fld29656, _Fld1353 FROM _InfoRg12907
всего 800 тысяч записей. Если мониторить план запроса, идет прям очень медленно около 50 записей в секунду. И все это по кластерному индексу. Если просто выполнить этот запрос, все 800 тысяч выбираются довольно быстро - 4 сек (и те наверно просто на передачу данных).
Пробовал ребилд индекса, обновление статистики - не помогло. Гугл ИИ говорит проблема не в скуле, а за пределами скуля..
Куда копать?

Копать в сторону BinaryData

(1) а подробнее можно?

(2) Что говорит

SELECT count(*)
  FROM [base1C].[dbo].[BinaryData]

  SELECT sum(datalength(f_data))/1024/1024
  FROM [base1C].[dbo].[BinaryData]

318430
1305

(4) Попробуйте на копии очистить таблицу binaryData и выгрузить dt-шник. Но вообще - не похоже, в принципе, адекватный размер.

(5) пока были на 2019 сервере вроде не жаловались

(6) Лучше попробовать, чем не попробовать

(5) Ошибка хранилища двоичных данных - 'Ошибка блочного хранения двоичных данных'

(8) В выходные поеду в Тверскую область, в лесу постараюсь найти костяк лося и погадаю на лопатке, что же вы имели ввиду, говоря "Ошибка хранилища двоичных данных". Нет, так то я знаю, что это за ошибка, но она настолько многогранна, что нужна лопатка лося.

(9) :) это после очистки таблицы выдал 1С конфигуратор при попытке выгрузки

(10) Очистки данных из таблицы или ее полного удаления? Она осталась в структуре таблиц SQL без записей, ведь так?

Что говорит

SELECT count(*)
  FROM [base1C].[dbo].[BinaryData]
?

(11) после truncate
(12) 0

(13) В конфигураторе попробовать ТИИ

(14) с пустым BinaryData?

(15) Да

Аналогичная проблема.
Выгрузка базы по объему в 3 раза больше проходит раз в 10-15 быстрее.
показатели запроса

312375
1895

(для сравнения на других базах, которые больше и выгружаются быстрее эти показатели нулевые)

(17) что по версиям систем у вас? Винда, скл, 1с?

Вы разбудили деда.

Создадим 2 справочника и наполним их одинаковым размером данных. Первый справочник будет содержать двоичные данные:
&НаСервере
Процедура СоздатьНаСервере()
    Двоичное=Новый ДвоичныеДанные("C:\tmp\tmp.trc");
    Для Сч=1 По 1000 цикл
        Элемент=Справочники.Справочник1.СоздатьЭлемент();
        Элемент.Наименование="Элемент"+Строка(Сч);
        Элемент.Реквизит1=Новый ХранилищеЗначения(Двоичное);
        Элемент.Записать();
    КонецЦикла;
КонецПроцедуры

Второй справочник - неограниченную строку:

&НаСервере
Процедура СоздатьНаСервере()
    Чтение=Новый ЧтениеТекста("D:\tmp\tmp.txt");
    Данные=Чтение.Прочитать();
    Для Сч=1 По 1000 цикл
        Элемент=Справочники.Справочник2.СоздатьЭлемент();
        Элемент.Наименование="Элемент"+Строка(Сч);
        Элемент.Реквизит1=Данные;
        Элемент.Записать();
    КонецЦикла;
КонецПроцедуры

Заполним 2 справочник строками по 6 Мб, получим базу в 6 Гб и выгрузим dt-шник. Он выгрузится почти мгновенно.

Заполним 1 справочник файлами по 6 Мб, получим базу в 12 Гб и выгрузим dt-шник. Он выгрузится за несколько минут.

Посмотрим хранилище запросов и нам всё станет понятно:

передайте это Владимиру Сергею.

(19) У меня кстати в плане запроса BinaryData не светится. Только Clustered Index Scan по _InfoRg12907

(20) что в общем то логично - в запросе нет его

(21) после того, как почистили binary - делали ТИИ с исправлением Двоичных?

(22) да, не дождался.. через пару часов сбросил

(23) Ну можно поставить на ночь, дождаться и потом попробовать выгрузить dt-шник. Уверен, что причина в (19).

Ну или перед выгрузкой dt сбросить хранилище запросов SQL и, как пройдет немного времени - посмотреть наиболее частные запросы - скорее всего будет как на картинке.

(24) ну ок.. допустим я увижу что это BinaryData тупит. что то сделать с этим можно?

А зачем в DT выгружать в наше время?

(26) Ну например, прод на сервере, а разработка в файловой.

(26) Например доступа к СУБД нет и админов хрен достучишься

(27) На разработку в файловой можно забить после появления лицензий для разработчиков

(25)[что то сделать с этим можно?]
платформу 1С одновременно с переходом на сиквел 2025 меняли ?

(29) И СУБД на отдельном сервере развернуть, да. Ну как бы да) У некоторых вообще отдельные связки под тестовые и разработку)))

Но бывает всякое.

(29) Ну у меня сейчас так. Скуль develop + 1c develop на рабочем компе  развернуты. Все лицензионно чисто.
Я по этому вопрос и задал.
Одна проблема в таких вариантах - нужно место под развернутые базы, а мегабайты нынче дороговаты.

(30) ну не одновременно, но примерно в пределах недели-двух. сейчас 8.5.1.1343

до этого долгое время было 8.3.27.1719

(26) Например перенос с одного сервера на другой, на одном MS SQL, на другом Postgres

(27) Бредово. А когда база под Парочку терабайт достигнет, тогда как? :)

(35) Это разовая операция, и время тут чисто заурядность.

Пример, бывает такое.
https://infostart.ru/1c/articles/1595040/

И приходится просто ждать :)

(36) >> Бредово.

Отнюдь. Это жизнь.
Далеко не всегда удобно разворачивать у себя сервер(ы) СУБД для доработок.
В особенности когда ты фрилансер с кучей клиентов, у каждого из которых свой зоопарк - у кого-то файловая (и это далеко не единицы), у кого-то MS SQL, у кого-то PoctgreSQL.
Понятно, что когда ты - разработчик в крупной компании, у тебя должны быть отдельные контуры разработки и тестирования со своими серверами приложений и СУБД версий аналогичных тем, что стоят в проде. Но это далеко не единственный сценарий работы 1С-ника.

>> А когда база под Парочку терабайт достигнет, тогда как?

Проблемы надо решать по мере их поступления, а не авансом на далёкое будущее, которое может никогда не наступить.