|
03.12.2021, 07:44 | #1 |
Administrator
|
Цитата:
Цитата:
SQL Server PDW drops tables from tempdb when:
Ну и самый простой способ проверить. Берем табличку в АХ, которая является временной в tempDB (например, TmpRecIdFilter). Пишем джобик на Х++ (класс в D365), где делаем select из этой таблицы, после чего получаем в локальную переменную значение метода cursor.getPhysicalTableName() - это и будет настоящее имя таблицы. Останавливаем исполнение кода в отладчике (чтобы сессия не закрылась), идем в SQL Manamegent Studio и делаем запрос select * from tempDB..[то имя, которое мы получили из метода getPhysicalTableName()]. После завершения работы джобика (если мы отпустим отладчик) этот запрос уже невозможно будет выполнить (будет ошибка)
__________________
Возможно сделать все. Вопрос времени Последний раз редактировалось sukhanchik; 03.12.2021 в 07:49. |
|
03.12.2021, 11:06 | #2 |
Moderator
|
Цитата:
Сообщение от sukhanchik
Ну и самый простой способ проверить. Берем табличку в АХ, которая является временной в tempDB (например, TmpRecIdFilter). Пишем джобик на Х++ (класс в D365), где делаем select из этой таблицы, после чего получаем в локальную переменную значение метода cursor.getPhysicalTableName() - это и будет настоящее имя таблицы. Останавливаем исполнение кода в отладчике (чтобы сессия не закрылась), идем в SQL Manamegent Studio и делаем запрос select * from tempDB..[то имя, которое мы получили из метода getPhysicalTableName()].
После завершения работы джобика (если мы отпустим отладчик) этот запрос уже невозможно будет выполнить (будет ошибка) Фраза "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 можно увидеть в основной БД какое-то количество таблиц с "временными" именами. |
|
|
За это сообщение автора поблагодарили: trud (5), sukhanchik (5), Logger (5), ax_mct (5). |
03.12.2021, 11:26 | #3 |
Участник
|
Цитата:
Сообщение от fed
С другой стороны, я неоднократно наблюдал такую картину: После скажем месяца аптайма останавливаем AOSы и оно как-то очень медленно останавливается. Если в этот момет понаблюдать за происходящим на сервере БД, то можно обнаружить что туда сотнями идут запросы вида Drop table tempdb.tXXXXXX_YYY..YYYY
Более того - если аос падает или его пристрелили не дожидаясь пока он сам остановится, то множество этих табличек во временной базе так и остаются пока не рестартуют SQL целиком. У меня коллега заморочился этим вопросом, даже написал скрипт по вычищению этих табличек. |
|
05.12.2021, 23:38 | #4 |
Участник
|
Цитата:
Сообщение от Logger
Да, точно так.
Более того - если аос падает или его пристрелили не дожидаясь пока он сам остановится, то множество этих табличек во временной базе так и остаются пока не рестартуют SQL целиком. У меня коллега заморочился этим вопросом, даже написал скрипт по вычищению этих табличек. X++: custTmpAccountSum.dispose(); |
|
|
За это сообщение автора поблагодарили: fed (5), Vadik (1), trud (2), sukhanchik (4), Logger (3), ax_mct (5), S.Kuskov (5). |
06.12.2021, 10:30 | #5 |
Участник
|
Цитата:
Сообщение от skuull
Возможно надо было просто поставить https://fix.lcs.dynamics.com/Issue/D...567?kb=3109258 ? Или руками перенести одну строку
X++: custTmpAccountSum.dispose(); Ссылка почему-то не открывается в хроме. Вот такая работает и открывается https://fix.lcs.dynamics.com/issue/results/?q=3109258 Похоже не все в этом обновлении исправлено. У коллеги используется CU13 и все суммы нулевые, т.е. маловероятно что вообще есть какая-то разноска в главную книгу, а проблема все равно присутствует. Но теперь понятно как это лечить. Последний раз редактировалось Logger; 06.12.2021 в 10:33. |
|
06.12.2021, 11:03 | #6 |
Moderator
|
Кстати - беглый эксперимент показал что он не только перестает плодить сотни одинаковых по структуре таблиц, но и начинает повторно использовать ранее выделенное имя таблицы. То есть, ситуация когда у нас plan cache на SQL Server оказался забит тысячами однообразных операторов вида
INSERT INTO tempdb."DBO".t66407IISMYVM1_915288_A59E0A988F0C4CBD8E436CC7D1C548E0... исчезает. По крайней мере в рамках цикла в одной сесии, если в конце цикла стоит dispose, то сгенерированное имя таблицы повторно используется на следующих итерациях... |
|
|
За это сообщение автора поблагодарили: sukhanchik (4), Logger (5). |
09.12.2021, 16:29 | #7 |
Участник
|
Цитата:
https://github.com/d365collaborative...empDbTables.md https://msdyn365fo.wordpress.com/201...x-environment/ |
|
|
За это сообщение автора поблагодарили: Logger (5). |
03.12.2021, 19:31 | #8 |
Administrator
|
Спасибо. Я не обращал на это внимание. Буду знать. Тогда прошу прощения за мое неверное понимание работы механизма
__________________
Возможно сделать все. Вопрос времени |
|
08.12.2021, 11:06 | #9 |
Участник
|
Цитата:
Сообщение от fed
Кстати - примерно полтора-два года назад, микрософт сделал новую фичу в D365FO, которая заставляет его в случае использования Azure SQL хранить tempDB таблицы в основной базе данных. И по моему эта фича уже год как включена и после экспорта данных из Tier2-instance можно увидеть в основной БД какое-то количество таблиц с "временными" именами.
Они же медленнее должны работать. Мусор в основной базе опять же. Это включено всегда теперь или можно как-то менять настройкой? |
|
08.12.2021, 11:32 | #10 |
Moderator
|
Цитата:
Если мне не изменяет память, раньше для включения/выключения этого режима был Flight, но сейчас я его что-то не смог найти. Наверное в случае Azure SQL режим включен намертво и не отключается. Последний раз редактировалось fed; 08.12.2021 в 11:42. |
|
|
За это сообщение автора поблагодарили: Logger (5). |