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

[faddy]

Есть кастомный SSRS отчет "Инвентарные списки".
До декабря 2021 г. отчет формировался без ошибки.
Сейчас возникает ошибка, пока только в одной компании, по одной модели учета, при отсутствии ограничения выборки основных средств из таблицы RAssetTable.
Текст ошибки:
«Невозможно создать запись в Инвентарные списки (RAssetInventorySheetTmp).
Возникла временная проблема с подключением к базе данных. Повторите попытку позже.»
При уменьшении количества выбранных основных средств путем задания фильтра в параметрах отчета по группе ОС
отчет формируется без ошибок.
При формировании отчета используются временные таблицы.

Кто нибудь встречался с подобной ошибкой? Не подскажете в какую сторону смотреть.

[SRF]

подозреваю, что вылетает исключение - Exception::TransientSqlConnectionError (https://docs.microsoft.com/en-us/dyn...nnection-error),

Но судя потому, что у вас отваливается регулярно и легко воспроизводится, получается превышается какой то порог по времени выполнения, вариантов не много, либо как то оптимизировать (например, запускать в несколько потоков), либо искать таймаут и его увеличивать, если это возможно.

[trud]

В 10.0.27 добавили анонсировали такой фикс, может быть он поможет

Цитата:

665562
Spike in "Tempdb table not present in database" after enabling fix for issue 642842 on the enviroment.

[faddy]

Да вылетает по Exception::TransientSqlConnectionError.
Обработка этого исключения в код добавлена, но это никак не повлияло на возникновение ошибки.
Отчет формируется долго, в ошибку вылетает примерно через 45-50 мин.
Но с уменьшенной выборкой данных формируется без ошибки за 2,5 часа.
Как-то не похоже что это по таймауту, может достигается порог по какому-то другому ресурсу ?

[fed]

Таблица RAssetInventorySheetTmp имеет тип InMemory, хранится в памяти/диске AOS и вообще не должна иметь отношения к базе данных.
Есть вариант что у вас просто кончается место на локальном диске облачного AOS, а поскольку среда исполнения не очень осознает различия в обработке настоящих временных таблиц БД и временных таблиц, она выдает диагностику Exception::TransientSqlConnectionError. (Хотя дело вообще не в базе данных).
Я бы попробовал сделать клон таблицы, сделать его TableType = TempDB и переделал бы отчет на использование этой таблицы. (Ну и класс отчета переделал бы на наследование от класса SrsReportDataProviderPreProcessTempDB )

[faddy]

Отчет полностью кастомный, и таблица имеет тип TempDB, а класс отчета является наследником SrsReportDataProviderPreProcessTempDB.
Кроме этого ради эксперимента пробовали использовать таблицу с типом Regular. Но проблема с ошибкой временного подключения к базе данных такая же.

[fed]

Цитата:

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

Отчет полностью кастомный, и таблица имеет тип TempDB, а класс отчета является наследником SrsReportDataProviderPreProcessTempDB.
Кроме этого ради эксперимента пробовали использовать таблицу с типом Regular. Но проблема с ошибкой временного подключения к базе данных такая же.

Может я чего-то не понимаю, но таблица RAssetInventorySheetTmp стандартная и имеет тип InMemory. Поменять тип таблицы через extension - нельзя. Ваше сообщение об ошибке упоминает именно эту таблицу. Вы уверены что у вас действительно таблица в режиме tempDB ?

[faddy]

Цитата:

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

Может я чего-то не понимаю, но таблица RAssetInventorySheetTmp стандартная и имеет тип InMemory. Поменять тип таблицы через extension - нельзя. Ваше сообщение об ошибке упоминает именно эту таблицу. Вы уверены что у вас действительно таблица в режиме tempDB ?

Отчет полностью не стандартный, и реально используемая таблица именуется примерно так: XXX_RAssetInventorySheetTmp с TableType = TempDB

[SRF]

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

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

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

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

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

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

[SRF]

Цитата:

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

Может я чего-то не понимаю, но таблица RAssetInventorySheetTmp стандартная и имеет тип InMemory. Поменять тип таблицы через extension - нельзя. Ваше сообщение об ошибке упоминает именно эту таблицу. Вы уверены что у вас действительно таблица в режиме tempDB ?

А разве через метод setTempDB нельзя сделать tempDB, или этот вызов работает только для регулярных таблиц ?

[Pandasama]

Цитата:

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

А разве через метод setTempDB нельзя сделать tempDB

Нет, inMemory нельзя сделать TempDB

[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).