D365FO Ошибка "Временная проблема с подключением к базе данных"

[faddy]

Цитата:

Сообщение от SRF

Да может конечно и другие какие то проблемы. Обычно какие-нибудь ошибки по месту выглядят как то более вразумительно, но исключать разумеется нельзя.

Насколько я понимаю отчет строится по принципу обхода query и в цикле идет вставка по одной записи или используется recordinsertlist ?

Интересно про 2.5 часа и regular - из 2.5 часов это все время идет обращение к бд, какое время занимает вывод уже готовых данных ?

Номер строки один и тот же на котором идет падение (возможно ли это как то проанализировать, например задав статическую сортировку в основном запросе ? ) С фильтрами по группам - по всем группам формируется отчет без ошибок ?

Я это к чему, возможно вы фильтрами выбиваете какие специфические данные, либо с фильтрами обращение к бд идет менее 45-50 минут.

В целом про какой объем строк в отчет идет речь ?

Отчет строится циклом по query - при этом отрабатывается определенная бизнес-логика сбора-получения дополнительных данных для отчета (необходимых пользователям дополнительных полей) и данные построчно записываются в TempDB таблицу через doinsert().
Пробовали переписать на использование recordinsertlist, но выгоды по времени формирования нет (т.к. основное время тратится на сбор дополнительных данных при заполнении recordinsertlist построчно), а ошибка оставалась.
С фильтрами по группе - первое что пробовали - получить отчет по каждой группе ОС отдельно и он формируется по всем группам без ошибки.
Еще замечено было, что если подобрать определенный список групп, с которым отчет формируется без ошибки, то непосредственно после обновления и перезапуска AOS отчет формируется без ошибки, а через некоторое время с точно таким же фильтром этот отчет падает в ошибку.
Строк в отчете менее 200 тысяч. Удавалось получить отчет без ошибки содержащий около 133 тыс. строк, причем на производственной среде.
На среде DEV ошибку вообще не удавалось воспроизвести и отчет содержал 158 тыс. строк.

[SRF]

Мда, если бы ошибка условно проявлялась только на tempdb, то возможно имело бы смысл посмотреть в сторону принудительной очистки времянок на БД (к слову, вот здесь недавно обсуждали Работа с TempDB-таблицами, там есть пара сообщений про изменения в tempdb для ssrs отчетов после которых были некоторые проблемы), поскольку есть повторные падения с одинаковыми параметрами.

Про recordinsertlist я скорее думал в плане сокращений количества вызовов к БД.

Я так понимаю сейчас обработка исключения выглядит - как повторный retry и там снова 40-50 минут и ошибка, да ?

А вот про обработку исключения такая мысль - вы смотрели остаются ли данные во времянке в БД ? Если остаются то возможно имеет смысл продолжить работу с данным экземпляром ?

Можно ли попробовать формировать данные "порциями" - например на каждый 50к-100к создавать отдельную tempdb, а затем их объединять, не знаю сработает ли такой вариант и насколько есть реальная потребность, даже если и заработает, то не понятно как дальше масштабировать (ведь насколько видно из описания дальше кол-во строк скорее всего будет только расти и будет расти время построения отчета).

Возможно имеет смысл посмотреть куда-нибудь в сторону ресурсоемких отчетов - предварительный расчет через ПО с многопоточным режимом, а дальше уже по этим данным формировать отчет.

[faddy]

Переписал отчет так:
Оставил весь наш код с логикой отчета, заполняющий временные таблицы.
Наследовал новый класс от XMLExcelReport_RU (существующий класс был наследован от SrsReportDataProviderPreProcessTempDB)
Убрал вывод через Reporting Services.
Сделал вывод отчета по "старинке" в файл Excel.

Тестирование показало, что данный вариант отчета формируется без ошибки с такими же параметрами, какие приводят к ошибке при формировании существующего варианта отчета.
Новый вариант отчета сформировался примерно за 4 часа 16 минут, количество строк в отчете 165 091.

По-видимому проблема не в кастомном коде, а в настройках Report Server или же в системном классе, от которого был наследован класс отчета (SrsReportDataProviderPreProcessTempDB, SrsReportDataProviderPreProcess).