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

[fed]

Цитата:

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

Ну и самый простой способ проверить. Берем табличку в АХ, которая является временной в tempDB (например, TmpRecIdFilter). Пишем джобик на Х++ (класс в D365), где делаем select из этой таблицы, после чего получаем в локальную переменную значение метода cursor.getPhysicalTableName() - это и будет настоящее имя таблицы. Останавливаем исполнение кода в отладчике (чтобы сессия не закрылась), идем в SQL Manamegent Studio и делаем запрос select * from tempDB..[то имя, которое мы получили из метода getPhysicalTableName()].

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

С другой стороны, я неоднократно наблюдал такую картину: После скажем месяца аптайма останавливаем AOSы и оно как-то очень медленно останавливается. Если в этот момет понаблюдать за происходящим на сервере БД, то можно обнаружить что туда сотнями идут запросы вида Drop table tempdb.tXXXXXX_YYY..YYYY
Фраза "A session is disconnected. Only temporary tables for the session are dropped." относиться, в моем понимании, только к временным таблицам самого SQL Server, имена которых, по правилам, должны начинаться с символов # или ##. А Аксаптовские tempDb таблицы, с точки зрения SQL Server, это самые обычные таблицы, вполне постоянные, только они храняться в tempDB и рестарта сервера БД не переживают. Я подозреваю, что как только таблица в Аксапте перемещается между SQL сессиями (например - после заполнения в серверном методе начинает использоваться как data source в форме; а все формы для броузинга таблиц используют одну shared-сессию), весь механизм автоматического удаления таблицы отключается и она (возможно после удаления из нее смысловых данных) болтается в БД до остановки AOS. Возможно микрософт просто не смог сделать нормального сборщика мусора для временных таблиц и часть из них удаляет только при останове сервера...

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

[Logger]

Цитата:

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

С другой стороны, я неоднократно наблюдал такую картину: После скажем месяца аптайма останавливаем AOSы и оно как-то очень медленно останавливается. Если в этот момет понаблюдать за происходящим на сервере БД, то можно обнаружить что туда сотнями идут запросы вида Drop table tempdb.tXXXXXX_YYY..YYYY

Да, точно так.
Более того - если аос падает или его пристрелили не дожидаясь пока он сам остановится, то множество этих табличек во временной базе так и остаются пока не рестартуют SQL целиком.

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

[skuull]

Цитата:

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

Да, точно так.
Более того - если аос падает или его пристрелили не дожидаясь пока он сам остановится, то множество этих табличек во временной базе так и остаются пока не рестартуют SQL целиком.

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

Возможно надо было просто поставить https://fix.lcs.dynamics.com/Issue/D...567?kb=3109258 ? Или руками перенести одну строку

custTmpAccountSum.dispose();

[Logger]

Цитата:

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

Возможно надо было просто поставить https://fix.lcs.dynamics.com/Issue/D...567?kb=3109258 ? Или руками перенести одну строку

custTmpAccountSum.dispose();

Спасибо.
Ссылка почему-то не открывается в хроме.
Вот такая работает и открывается
https://fix.lcs.dynamics.com/issue/results/?q=3109258

Похоже не все в этом обновлении исправлено.
У коллеги используется CU13 и все суммы нулевые, т.е. маловероятно что вообще есть какая-то разноска в главную книгу, а проблема все равно присутствует. Но теперь понятно как это лечить.

[fed]

Цитата:

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

custTmpAccountSum.dispose();

Кстати - беглый эксперимент показал что он не только перестает плодить сотни одинаковых по структуре таблиц, но и начинает повторно использовать ранее выделенное имя таблицы. То есть, ситуация когда у нас plan cache на SQL Server оказался забит тысячами однообразных операторов вида
INSERT INTO tempdb."DBO".t66407IISMYVM1_915288_A59E0A988F0C4CBD8E436CC7D1C548E0... исчезает. По крайней мере в рамках цикла в одной сесии, если в конце цикла стоит dispose, то сгенерированное имя таблицы повторно используется на следующих итерациях...

[vmoskalenko]

Цитата:

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

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

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

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

[sukhanchik]

Цитата:

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

С другой стороны, я неоднократно наблюдал такую картину

Спасибо. Я не обращал на это внимание. Буду знать. Тогда прошу прощения за мое неверное понимание работы механизма

[Logger]

Цитата:

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

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

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

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

[fed]

Цитата:

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

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

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

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