После переход на новый сервер 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) Да