| 1C |
hiddi, Lama12, vicof, H A D G E H O G s, sikuda, Доминошник, ptiz, viraboy, Karamzin, HobbyHorser, Zamestas, Климов Сергей, Волшебник, Vstur, obs191, Elf_80_lvl, Шурик71, shuhard, 1cVandal, MichK, NorthWind, RomanYS, ГдеСобакаЗарыта, Bad_Aleks, 2S, kubik_live, Garykom, Homer, Террз
☑
13.05.26
✎
00:50
После переход на новый сервер 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 сек (и те наверно просто на передачу данных).
Пробовал ребилд индекса, обновление статистики - не помогло. Гугл ИИ говорит проблема не в скуле, а за пределами скуля..
Куда копать?
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 сек (и те наверно просто на передачу данных).
Пробовал ребилд индекса, обновление статистики - не помогло. Гугл ИИ говорит проблема не в скуле, а за пределами скуля..
Куда копать?
13.05.26
✎
00:51
Копать в сторону BinaryData
13.05.26
✎
00:54
(1) а подробнее можно?
13.05.26
✎
00:57
(2) Что говорит
SELECT count(*)
FROM [base1C].[dbo].[BinaryData]
SELECT sum(datalength(f_data))/1024/1024
FROM [base1C].[dbo].[BinaryData]
SELECT count(*)
FROM [base1C].[dbo].[BinaryData]
SELECT sum(datalength(f_data))/1024/1024
FROM [base1C].[dbo].[BinaryData]
13.05.26
✎
01:11
318430
1305
1305
13.05.26
✎
01:17
(4) Попробуйте на копии очистить таблицу binaryData и выгрузить dt-шник. Но вообще - не похоже, в принципе, адекватный размер.
13.05.26
✎
01:19
(5) пока были на 2019 сервере вроде не жаловались
13.05.26
✎
01:33
(6) Лучше попробовать, чем не попробовать
13.05.26
✎
01:58
(5) Ошибка хранилища двоичных данных - 'Ошибка блочного хранения двоичных данных'
13.05.26
✎
02:17
(8) В выходные поеду в Тверскую область, в лесу постараюсь найти костяк лося и погадаю на лопатке, что же вы имели ввиду, говоря "Ошибка хранилища двоичных данных". Нет, так то я знаю, что это за ошибка, но она настолько многогранна, что нужна лопатка лося.
13.05.26
✎
02:25
(9) :) это после очистки таблицы выдал 1С конфигуратор при попытке выгрузки
13.05.26
✎
02:35
(10) Очистки данных из таблицы или ее полного удаления? Она осталась в структуре таблиц SQL без записей, ведь так?
13.05.26
✎
02:37
Что говорит
SELECT count(*)
FROM [base1C].[dbo].[BinaryData]
?
SELECT count(*)
FROM [base1C].[dbo].[BinaryData]
?
13.05.26
✎
08:06
(11) после truncate
(12) 0
(12) 0
13.05.26
✎
10:15
(13) В конфигураторе попробовать ТИИ
|
13.05.26
✎
10:19
(14) с пустым BinaryData?
13.05.26
✎
10:20
(15) Да
18.05.26
✎
15:38
Аналогичная проблема.
Выгрузка базы по объему в 3 раза больше проходит раз в 10-15 быстрее.
показатели запроса
312375
1895
(для сравнения на других базах, которые больше и выгружаются быстрее эти показатели нулевые)
Выгрузка базы по объему в 3 раза больше проходит раз в 10-15 быстрее.
показатели запроса
312375
1895
(для сравнения на других базах, которые больше и выгружаются быстрее эти показатели нулевые)
18.05.26
✎
21:43
(17) что по версиям систем у вас? Винда, скл, 1с?