26.04.2022, 08:35 | #11 |
Участник
|
Мда, если бы ошибка условно проявлялась только на tempdb, то возможно имело бы смысл посмотреть в сторону принудительной очистки времянок на БД (к слову, вот здесь недавно обсуждали Работа с TempDB-таблицами, там есть пара сообщений про изменения в tempdb для ssrs отчетов после которых были некоторые проблемы), поскольку есть повторные падения с одинаковыми параметрами.
Про recordinsertlist я скорее думал в плане сокращений количества вызовов к БД. Я так понимаю сейчас обработка исключения выглядит - как повторный retry и там снова 40-50 минут и ошибка, да ? А вот про обработку исключения такая мысль - вы смотрели остаются ли данные во времянке в БД ? Если остаются то возможно имеет смысл продолжить работу с данным экземпляром ? Можно ли попробовать формировать данные "порциями" - например на каждый 50к-100к создавать отдельную tempdb, а затем их объединять, не знаю сработает ли такой вариант и насколько есть реальная потребность, даже если и заработает, то не понятно как дальше масштабировать (ведь насколько видно из описания дальше кол-во строк скорее всего будет только расти и будет расти время построения отчета). Возможно имеет смысл посмотреть куда-нибудь в сторону ресурсоемких отчетов - предварительный расчет через ПО с многопоточным режимом, а дальше уже по этим данным формировать отчет.
__________________
Sergey Nefedov |
|
Теги |
d365fo |
|
|