Работа с TempDB-таблицами

[Logger]

Цитата:

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

Кстати - примерно полтора-два года назад, микрософт сделал новую фичу в D365FO, которая заставляет его в случае использования Azure SQL хранить tempDB таблицы в основной базе данных. И по моему эта фича уже год как включена и после экспорта данных из Tier2-instance можно увидеть в основной БД какое-то количество таблиц с "временными" именами.

А зачем это сделали ?
Они же медленнее должны работать.
Мусор в основной базе опять же.

Это включено всегда теперь или можно как-то менять настройкой?

[fed]

Цитата:

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

А зачем это сделали ?
Они же медленнее должны работать.
Мусор в основной базе опять же.

Это включено всегда теперь или можно как-то менять настройкой?

Рискну предположить, что сделали это при переходе на Spartan - разделяемый пул Azure SQL Server. Если у меня несколько разных компаний (в смысле - разных несвязанных между собой клиентов Microsoft) на одном сервере живет, то можно попытаться прочитать чужие данные из tempDB. (не уверен что это так просто, но можно попробовать поискать в SQL Dictionary данные по таблицам в tempDB и потом попробовать почитать из каждой таблицы).
Если мне не изменяет память, раньше для включения/выключения этого режима был Flight, но сейчас я его что-то не смог найти. Наверное в случае Azure SQL режим включен намертво и не отключается.

[fed]

Ладно - раз уж речь зашла о таблицах tempDB:
Как выяснилось, отключение функциональности Engineering Change в D365FO может очень прилично ускорить массовую вставку строк в складские журналы, заказы и sales quotation.
Есть такой метод: EngChgEcoResProductLifecycleStateRuleCheck::validateFilter(), который срабатывает при вставках в упомянутые выше таблицы. Этот метод копирует данные из таблицы в ее клон в tempDB и потом прогоняет запрос по этой временной копии. (можно у обычной, не временной таблицы вызвать метод vendTable.setTempDB() и система создаст tempDb-клон обычной таблицы) . Dispose() после этого не вызывается, соответственно на каждую вставку система генерирует уникальное новое имя временной таблицы, прогоняет по этой таблице запрос и тд. Если вставка идет в ручную (скажем - 300-400 строк заказов в час), то эти самые левые запросы в SQL Plan Cache погоды не делают. Если у нас имеется массовый импорт и мы пытаемся быстро залить скажем тысяч 20-30 строк, уникальные имена таблиц забивают Plan Cache, загоняя SQL Server на ёлку. (Кэш сбрасывается каждые 20-30 секунд и все запросы попадают на рекомпиляцию). Конечно скорость убивания SQL Server зависит от объема памяти на таковом и числа импортируемых строк, но вот например в моей VM, при ограничении размера памяти SQ Server в 8 Мб для того чтобы загнать сервер на ёлку достаточно было достаточно смешных 1500 строк в складских журналах...

[skuull]

В копилку проблем, относительно недавно поменяли что-то с tempdb и раньше preprocessed отчёты которые на tempdb каждый раз создавали новую таблицу но после чейнджа они начали браться из пула но криво. И какое-то время отчёты могли показывать старые данные. После пары нерешённых багов с мс мы на них забили, так что я хз есть ли с этим ещё проблемы и берутся все таблицы из пула или только отчёты.

[skuull]

Цитата:

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

В копилку проблем, относительно недавно поменяли что-то с tempdb и раньше preprocessed отчёты которые на tempdb каждый раз создавали новую таблицу но после чейнджа они начали браться из пула но криво. И какое-то время отчёты могли показывать старые данные. После пары нерешённых багов с мс мы на них забили, так что я хз есть ли с этим ещё проблемы и берутся все таблицы из пула или только отчёты.

За это отвечает(отвечал) volatile_isconnectionleveltempdbpoolenabled флаг в sysglobalconfiguration

[vmoskalenko]

Цитата:

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

У меня коллега заморочился этим вопросом, даже написал скрипт по вычищению этих табличек.

Ссылки на утилиты
https://github.com/d365collaborative...empDbTables.md

https://msdyn365fo.wordpress.com/201...x-environment/

[Logger]

Делаю модификацию, которая организует некий кеш в TempDb таблице.
При закрытии аксапты хочется корректно его освободить. Т.е. вызвать
tempDb.dispose()

Где правильнее всего разместить этот вызов ?
Напрашивается
\Classes\Application\closingDown

[mazzy]

Цитата:

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

Где правильнее всего разместить этот вызов ?
Напрашивается
\Classes\Application\closingDown

при падении Аксапты кэш не будет очищен.

"некий кеш" лучше организовывать при помощи стандартного кэш сервера. например Redis.
В том же Redis есть автопротухание данных.

тогда и несколько инстансев аксапты будут нормально работать.
и другие неаксаптовские подсистемы спасибо скажут.
и эцилопп не имеет права бить по ночам. никогда.

[Logger]

Цитата:

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

при падении Аксапты кэш не будет очищен.

Это да.
Но я и не надеялся такое вылечить. Не все под силу.
Там много г. во временной базе остается при падении аоса.

Это у меня не совсем кеш. Я не совсем корректный термин употребил. В общем времянка хранит некие данные актуальные только для конкретного юзера. Т.е. у каждого юзера свое наполнение.

Соответственно вопрос, с учетом багов ядра по освобождению времянок, куда корректно было бы поместить вызов dispose() для времянки.

Может кто делал и проверял как работает.
Интересно также CIL сессии и те, что создаются по RunAs. Для них ядро вызывает closingDown ?

Хотелось остаться внутри аксапты и не привлекать сторонние инструменты (Redis, etc)

[fed]

Мне кажется что проблема зависших времянок в tempDb не так страшна. Когда AOS будет останавливаться, времянки удалятся.
Проблема с времянками в том, что если ты их в цикле создаешь, а потом через dispose() не освобождаешь, то кэш плана запроса забивается тысячам одинаковых запросов, у которых только имя временной таблицы отличается. В твоем случае гарантируется что всего один инстанц времянки на пользователя будет и даже если пользователь из системы выйдет, а времянка не удалится, то новых запросов в кэше по ней появлятся не будет. То есть - я бы с этой проблемой просто не стал бы бороться.

[Logger]

Да, циклов там не будет.
Согласен, что несущественная проблема.
Просто все мы стремимся к идеалу, хоть чуть-чуть.

Вот и возникает вопрос.
А как бы правильно ...

[fed]

Опыт показал, что если в классе создать переменную типа tempDB, положить туда данные, потом FormDataSource прикрепить к этому же инстанцу временной таблицы через myDataSource_ds.cursor().linkPhysicalTableInstance(MyCalculationClass.tempDbBuffer()), а потом вызвать для исходных табличных переменных из MyCalculationClass метод Dispose(), то последствия бывают самые интересные и не вполне предсказуемые. В том числе иногда падает Productive AOS
Я так понимаю, когда форма закрывается, переменные с датасорцами не освобождаются немедленно, а ждут сборки мусора. Потом в какой-то момент времени сборщик мусора просыпается, пытается удалить датасорцы и прикрепленные к ним табличные переменные, а там опаньки - табличные переменные-то уже кто-то удалил. В итоге сервер с заметной вероятностью падает.
В общем - похоже что после linkPhysicalTableInstance() вызывать Dispose для табличных переменных просто нельзя.
P.S. D365FO. Но я подозреваю что в DAX2012 грабли аналогичной конструкции.

[Raven Melancholic]

Цитата:

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

Опыт показал, что если в классе создать переменную типа tempDB, положить туда данные, потом FormDataSource прикрепить к этому же инстанцу временной таблицы через myDataSource_ds.cursor().linkPhysicalTableInstance(MyCalculationClass.tempDbBuffer()), а потом вызвать для исходных табличных переменных из MyCalculationClass метод Dispose(), то последствия бывают самые интересные и не вполне предсказуемые. В том числе иногда падает Productive AOS
...
В общем - похоже что после linkPhysicalTableInstance() вызывать Dispose для табличных переменных просто нельзя.
P.S. D365FO. Но я подозреваю что в DAX2012 грабли аналогичной конструкции.

Да, совсем недавно на 2012 с этим столкнулся.
Правда у меня падает не АОС, а клиент и не через некоторое время, а практически сразу при закрытии формы.

Но и кейс немного другой, я вызываю linkPhysicalTableInstance не на датасорсе, а наоборот, передаю курсор датасорса и его прикрепляю к локальной переменной:

public void inventToShipPrepare(
    ShipmentJournalRequestMap_OVK   _journalRequest,
    ShipmentInventToShipMap_OVK     _inventToShip
    )
{
    ShipmentInventToShipMap_OVK         inventToShip;
    ;
    
    inventToShip        = _inventToShip.emptyRecord();
    if (_inventToShip.isTempDb())
    {
        inventToShip.linkPhysicalTableInstance(_inventToShip);
    }

...

    // TODO: AKlim 12.10.2022 Попробовать разобраться в причине падения клиента
    //       Пока освобождение закомментировано, так как падает клиент при закрытии формы
    /*    
    if (_inventToShip.isTempDb())
    {
        inventToShip.dispose();
    }
    */
}

[Logger]

Крайне неприятный баг.
Использованные вами методы работают со ссылкой на переменную. Возможно из-за этого дополнительные зависимости появляются и поэтому падает.

А если задействовать методы ?
getPhysicalTableName
useExistingTempDBTable

Там просто реальное SQL имя таблички передается.
Возможно не будет падать.
Я в своей модификации использовал их - не падало. Правда сценарий был немного другой.

[fed]

Цитата:

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

Крайне неприятный баг.
...
А если задействовать методы ?
getPhysicalTableName
useExistingTempDBTable

Я на эту тему думал, но мы решили, что это все равно настроечная форма, которой в месяц раз пять пользуются. Соответственно - пять мусорных временных табличек в месяц - это дешевле чем эксперименты, которые иногда сервер роняют. (При этом о том, что AOS от этой функциональности иногда падает, мы знали с февраля примерно, но комбинацию данных, при которой это железно происходит - выловили только неделю назад).

[bio_unit]

То, что сервер роняет - это еще ничего...
Мы столкнулись на D365, что при неумелом использовании dispose и передаче tempDb таблиц через простое присваивание переменных, может быть эффект удаления данных из реальных таблиц БД.

delete_from tmpSomeTable;

Видимо, когда сборщик мусора отрабатывает, то tmpSomeTable может ссылать на какой-то произвольный курсор, какой-то случайной таблицы и delete_from отрабатывает по какой-то произвольной физической таблице БД.
Например, в одном случае - CustParameters, в другом - InventTable.
Из таблиц БД начинают "загадочно" пропадать данные.

[Logger]

Цитата:

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

То, что сервер роняет - это еще ничего...
Мы столкнулись на D365, что при неумелом использовании dispose и передаче tempDb таблиц через простое присваивание переменных, может быть эффект удаления данных из реальных таблиц БД.

А как лечили ?

Убирали

delete_from tmpSomeTable;

Отказались от dispose ?

[Zabr]

Цитата:

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

Как выяснилось, отключение функциональности Engineering Change в D365FO может очень прилично ускорить массовую вставку строк в складские журналы, заказы и sales quotation.

Где включается и отключается Engineering Change, покажите пожалуйста? лучше со скриншотом. Мы у себя найти не смогли. Наша версия D365FO:
Установленная версия продукта: 10.0.26 (10.0.1192.146)
Установленная версия платформы: Update50 (7.0.6354.130)

[fed]

Цитата:

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

Где включается и отключается Engineering Change, покажите пожалуйста? лучше со скриншотом. Мы у себя найти не смогли. Наша версия D365FO:
Установленная версия продукта: 10.0.26 (10.0.1192.146)
Установленная версия платформы: Update50 (7.0.6354.130)

У нас сейчас 10.0.34 и в feature management я вижу вот такую фичу. Но вообще-то для версии 10.0.34 совет уже не актуален. Где-то между 10.0.2x (где я эту проблему нашел) и 10.0.34 микрософт подправил код метода EngChgEcoResProductLifecycleStateRuleCheck.validateFilter() и там вместо tempDB таблицы используется обычная inMemory table. Учитывая что в этом методе таблица использвется для одной и только одной записи, вариант в InMemory не только решает проблемы с зависшими tempDB таблицами, но и еще экономит время исполнения.