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

[ax_mct]

Цитата:

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

TempDB-таблицы себя замечательно ведут и замечательно джойнятся. А уж тот факт, что RecId там является счетчиком, который управляется СУБД - вообще достойно уважения. Так что джойны с TempDB-шными таблицами очень даже хороши. Особенно, когда нужно отфильтровать по списку RecId (RecordReferenceList тоже работает - но его потом нужно чистить)

Один черт страшно.
Вот как там в Prod Azure DB TempDB чистится? Черт его знает.

[sukhanchik]

Цитата:

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

Один черт страшно.
Вот как там в Prod Azure DB TempDB чистится? Черт его знает.

Там принцип простой. Берется таблица, структура которой определена в АОТ и при первом обращении - создается таблица в TempDB под названием tXXXXXX_YYY..YYYY, где XXXXX Х - это TableId таблички, а YYY..YYYY - некоторый перечень букв, который формируется случайным образом при первом вызове select из кода. Повторное обращение в Х++ к этой же таблице другой переменной (через select) без использования метода linkToPhysicalInstance - создает вторую такую же таблицу, где первая часть tXXXXXX_ - такая же, а YYY..YYYY - уже другая.

Старый объект удаляется, как только он становится не нужным. Поэтому таблица как таковая не чистится - она просто становится мусором. И через некоторое время то место, на котором она находилась в файле базы TempDB - перезаписывается данными другой временной таблицы.
Поэтому тут никаких чисток нет, принцип един и общий и какой-то мегаособенности работы SQL Server с TempDB в Azure (по сравнению с локальной версией) нет.

[trud]

Цитата:

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

Старый объект удаляется, как только он становится не нужным. Поэтому таблица как таковая не чистится - она просто становится мусором. И через некоторое время то место, на котором она находилась в файле базы TempDB - перезаписывается данными другой временной таблицы.

Вот это кстати интерестный момент. А кто ее удаляет? На одном из клиентов наблюдал что таблицы были в большом кол-ве в tempdb

[sukhanchik]

Цитата:

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

Вот это кстати интерестный момент. А кто ее удаляет? На одном из клиентов наблюдал что таблицы были в большом кол-ве в tempdb

https://docs.microsoft.com/en-us/sql...empdb-database

Цитата:

SQL Server PDW drops tables from tempdb when:

• The DROP TABLE statement is executed.
  
• A session is disconnected. Only temporary tables for the session are dropped.
  
• The appliance is shutdown.
  
• The Control node has a cluster failover.

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

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

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

[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();

[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 режим включен намертво и не отключается.