|
02.12.2021, 22:16 | #1 |
Administrator
|
Работа с TempDB-таблицами
*** Выделено изQuery::Insert_recordset() - выборка из временной таблицы ***
Цитата:
__________________
Возможно сделать все. Вопрос времени Последний раз редактировалось sukhanchik; 03.12.2021 в 19:32. |
|
03.12.2021, 00:50 | #2 |
Banned
|
Цитата:
Сообщение от sukhanchik
TempDB-таблицы себя замечательно ведут и замечательно джойнятся. А уж тот факт, что RecId там является счетчиком, который управляется СУБД - вообще достойно уважения. Так что джойны с TempDB-шными таблицами очень даже хороши. Особенно, когда нужно отфильтровать по списку RecId (RecordReferenceList тоже работает - но его потом нужно чистить)
Вот как там в Prod Azure DB TempDB чистится? Черт его знает. |
|
03.12.2021, 01:39 | #3 |
Administrator
|
Цитата:
Старый объект удаляется, как только он становится не нужным. Поэтому таблица как таковая не чистится - она просто становится мусором. И через некоторое время то место, на котором она находилась в файле базы TempDB - перезаписывается данными другой временной таблицы. Поэтому тут никаких чисток нет, принцип един и общий и какой-то мегаособенности работы SQL Server с TempDB в Azure (по сравнению с локальной версией) нет.
__________________
Возможно сделать все. Вопрос времени |
|
03.12.2021, 02:27 | #4 |
Участник
|
Вот это кстати интерестный момент. А кто ее удаляет? На одном из клиентов наблюдал что таблицы были в большом кол-ве в tempdb
|
|
03.12.2021, 07:44 | #5 |
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 | #6 |
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, 07:43 | #7 |
Участник
|
Так с InMemory временными таблицами (а до DAX2012 просто с временными таблицами) никакой оптимизации и не будет в массовых обработчиках. Только может быть более лаконичный синтаксис, а обработка всё равно будет по каждой записи.
|
|
03.12.2021, 13:10 | #8 |
Участник
|
А из участников обсуждения есть модераторы?
Может стоит перенести обсуждение особенностей работы Аксы с TempDB в отдельную ветку? Ну чтобы впоследствии, если кто будет искать именно работу с Query::Insert_recordset, получали более сконцентрированную информацию, а кто искал бы особенности TempDB получил своё. |
|
|
За это сообщение автора поблагодарили: sukhanchik (4). |
03.12.2021, 19:55 | #9 |
Banned
|
Цитата:
Сообщение от fed
Единственная реальная проблема с временными таблицами tempDB(а на самом деле - это ОБЫЧНЫЕ таблицы, просто система их автоматически удаляет) - это возможность засорить sql statement cache. То есть - если у тебя в D365FO стоит такой вот примерно код: for(i=0;i<10000;i++) { myFavoritetempDbTable myTable; //do something with the table } то велика вероятность того, что система создаст 10000 одинаковых временных таблиц с разными именами, потом отправит 10000 разных запросов на вставку и выборку и тп. В результате кэш сиквела затрешиться. Но от такого антипаттерна легко защититься, добавив еще одно поле для хранения i во временную таблицу, создать только один экземпляр этой временной таблицы и просто во все запросы добавить условие myTable.fieldI == i А InMemory временные таблицы изначально были достаточно бесполезной штукой. Запросы с их участием обрабатывались на AOS (То есть - из запроса исключалась временная таблица, остатки запроса отправлялись на SQL, оттуда приходил результат - зачастую сотни мегабайт, результат записывался куда-то на AOSовский диск и потом это все медленно и печально джойнилось с inMemory table где-то на дисках AOS). Если просто быстродействия хочется (без необходимости джойнить временную таблицу куда-то), то лучше Map или там List использовать, потому что они в памяти остаются, а не высвопляются на диск AOS если в таблице больше нескольких сотен записей образовалось. https://community.dynamics.com/ax/f/...-tempdb/898314 Assuming you don't have basic configuration issues with your TempDB, i.e. too small with not enough auto-expand, insufficient storage on the hosting volume, not enough files per the recommended configuration, sufficiently fast storage to handle you workload, etc., you could have one of two types of problems. First, [упоминается проблема когда просто не влезает] но можно как-то увидеть. Second, [упоминается проблема c версиями записей при долгом запросе] что нелегко идентифицировать. Цитата:
То есть при использовании TempDB мы отвечаем за наше некое решение, в котором полагаемся на то что вне нашего контроля. Возможно сказать что это не ответственность программиста раз штатное средство, но клиент нанимает опытных специалистов именно за их интуитивное избегание ненужных проблем. Последний раз редактировалось ax_mct; 03.12.2021 в 19:59. |
|
03.12.2021, 20:46 | #10 |
Administrator
|
Цитата:
Вариант 1. Когда программист не может полагаться на админов. Вариант 2. Когда программист может полагаться на админов, вплоть до самостоятельного умения обслужить сервер Если нужно обработать большой объём данных (такое количество данных, обработка которых занимает больше 6 часов (цифра абстрактная и приближена к длительности рабочего дня программиста), то неизбежно приходим к варианту 2. В этом случае собственно - есть выбор - грузить ли данные в оперативную память (раздувать память, потребляемую AOS / IIS / Batch, используя Set, List и т.п. объекты), либо "променять" оперативную память на временные таблицы и джойнить таблицы уже на уровне СУБД. Ну и собственно при превышении некоторого порога обрабатываемого объёма данных - уже приходится работать с СУБД и админами СУБД. Так сказать в тесном контакте. Но в этом случае и заказчик обычно понимает и не пренебрегает этой необходимостью. Поэтому временные таблицы и постоянные в роли временных - достаточно неплохо выполняют свою роль. И как-то лично мне последнее время "везёт" на вопросы оптимизации БД. Собственно, поэтому я и ратую за TempDB, после того, как столкнулся с достаточно большим потреблением памяти AOS при использовании List / Set и прочих классов, которые генерируются в оперативной памяти
__________________
Возможно сделать все. Вопрос времени |
|
04.12.2021, 00:40 | #11 |
Banned
|
Цитата:
Я бы и рад контролировать сервер баз данных, но это очень не принято в больших компаниях. Более того вообще другая организация может отвечать за СУБД. То есть полное разделение кода от данных А с облачным D365FO когда Azure DB и в руках блаженных, то какой тут Вариант 2. Вариант 1 это на мой взгляд 90% рынка. Когда программист даже не знает кто или что за базу отвечает. Необходимости взаимодействия никто даже и не поймет. Цитата:
-насколько это критично? -сколько памяти на AOS? |
|
05.12.2021, 18:50 | #12 |
Administrator
|
Цитата:
Задача: Сделать начальную заливку данных (точнее - подготовиться к этому). При этом многие данные для перелива большие (накладные / заказы за период и т.д.) в части количества записей, поэтому начинаем пробовать на некоторых справочниках, где количество записей условно небольшое (1,3 млн). При этом все понимают, что период заливки будет достаточно большим и после заливки скорее всего придется подгружать свежие данные. При этом во время заливки могут быть те или иные ошибки (в данных), которые хочется подправить и продолжить заливку с того места, где возникла ошибка, а не перезапускать всю процедуру заново. Если во время процедуры заливки будет падать АОС, Windows и т.д., то также не хочется запускать всё заново, а хочется продолжения работы с того же места. В процессе программирования и прогона - запускается процедура переливки. Пока она идет - можно смотреть в БД и с удовольствием смотреть на увеличивающееся количество записей в нужных таблицах. Параллельно смотреть на ресурсы сервера - если идет "упор" в диски - анализировать БД и индексы. Если увеличивается объем памяти, потребляемый АОСом - то анализировать причины в т.ч. Trace Parser-ом. Ситуация. Вижу, что АОС после запуска процедуры переливки начинает достаточно быстро отбирать гигабайты памяти (условно - пусть он "отъел" с 8 до 20 Гб). При этом записей создалось несравнимо мало. Стопаю пакетник, иду разбираюсь. Вижу, что есть цикл, который перебирает записи и формирует List из некоторых записей (отобранных кодом). Позже вижу, что этот перечень используется для формирования данных в других таблицах. Возникает 2 мысли: - а почему бы просто не перебрать эти записи через Query ? - а почему бы не складировать RecId отобранных записей в TempDB-шную табличку, а потом ее приджойнить для выборки ? Но для начала отключаю формирование List-а. Перезапускаю процедуру и вижу, что потребление памяти становится медленнее. Также замечаю, что есть код, где в цикле создаются новые экземпляры классов. Перестраиваю код так, чтобы этого не было. Чтобы классы создавались либо до цикла, либо уже в методах в локальных переменных, которые вызываются из цикла. Это еще снижает скорость потребления памяти. Цель всей этой работы - гарантированно перелить начальные данные в час Х, когда по сути будет условно одна попытка Поэтому тут нет конкретных цифр, но хочется исключить всякие сюрпризы в т.ч. от переобъевшегося АОСа. Ну и конечно - задача максимально сократить общее время на перелив.
__________________
Возможно сделать все. Вопрос времени |
|
|
За это сообщение автора поблагодарили: ax_mct (7). |
07.12.2021, 20:22 | #13 |
Banned
|
Цитата:
Сообщение от sukhanchik
Не.... тут всё не так
Задача: Сделать начальную заливку данных (точнее - подготовиться к этому). ... - а почему бы просто не перебрать эти записи через Query ? - а почему бы не складировать RecId отобранных записей в TempDB-шную табличку, а потом ее приджойнить для выборки ? Цель всей этой работы - гарантированно перелить начальные данные в час Х, когда по сути будет условно одна попытка Поэтому тут нет конкретных цифр, но хочется исключить всякие сюрпризы в т.ч. от переобъевшегося АОСа. Ну и конечно - задача максимально сократить общее время на перелив. Спасибо за обьяснение! |
|
05.12.2021, 18:19 | #14 |
Moderator
|
Цитата:
Сообщение от ax_mct
First, [упоминается проблема когда просто не влезает] но можно как-то увидеть. Second, [упоминается проблема c версиями записей при долгом запросе] что нелегко идентифицировать. Именно. Программист может полагаться на сборщик мусора, не C++ в конце концов, но чтобы твой код полагался на то что на стороне SQL Server адекватное администрирование и ресурсы, это слишком оптимистично. То есть при использовании TempDB мы отвечаем за наше некое решение, в котором полагаемся на то что вне нашего контроля. Возможно сказать что это не ответственность программиста раз штатное средство, но клиент нанимает опытных специалистов именно за их интуитивное избегание ненужных проблем. В первом случае по крайней мере лечге понять что именно сломалось. |
|
08.12.2021, 12:49 | #15 |
Moderator
|
Ладно - раз уж речь зашла о таблицах 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 строк в складских журналах... Последний раз редактировалось fed; 08.12.2021 в 15:32. |
|
|
За это сообщение автора поблагодарили: EVGL (8), sukhanchik (6). |
13.12.2023, 11:43 | #16 |
Участник
|
Цитата:
Установленная версия продукта: 10.0.26 (10.0.1192.146) Установленная версия платформы: Update50 (7.0.6354.130) |
|
13.12.2023, 13:41 | #17 |
Moderator
|
У нас сейчас 10.0.34 и в feature management я вижу вот такую фичу. Но вообще-то для версии 10.0.34 совет уже не актуален. Где-то между 10.0.2x (где я эту проблему нашел) и 10.0.34 микрософт подправил код метода EngChgEcoResProductLifecycleStateRuleCheck.validateFilter() и там вместо tempDB таблицы используется обычная inMemory table. Учитывая что в этом методе таблица использвется для одной и только одной записи, вариант в InMemory не только решает проблемы с зависшими tempDB таблицами, но и еще экономит время исполнения.
|
|
|
За это сообщение автора поблагодарили: Zabr (3), sukhanchik (5). |
09.12.2021, 08:31 | #18 |
Участник
|
В копилку проблем, относительно недавно поменяли что-то с tempdb и раньше preprocessed отчёты которые на tempdb каждый раз создавали новую таблицу но после чейнджа они начали браться из пула но криво. И какое-то время отчёты могли показывать старые данные. После пары нерешённых багов с мс мы на них забили, так что я хз есть ли с этим ещё проблемы и берутся все таблицы из пула или только отчёты.
|
|
09.12.2021, 10:42 | #19 |
Участник
|
Цитата:
Сообщение от skuull
В копилку проблем, относительно недавно поменяли что-то с tempdb и раньше preprocessed отчёты которые на tempdb каждый раз создавали новую таблицу но после чейнджа они начали браться из пула но криво. И какое-то время отчёты могли показывать старые данные. После пары нерешённых багов с мс мы на них забили, так что я хз есть ли с этим ещё проблемы и берутся все таблицы из пула или только отчёты.
|
|
|
За это сообщение автора поблагодарили: sukhanchik (4), Logger (3). |
11.07.2022, 13:20 | #20 |
Участник
|
Делаю модификацию, которая организует некий кеш в TempDb таблице.
При закрытии аксапты хочется корректно его освободить. Т.е. вызвать tempDb.dispose() Где правильнее всего разместить этот вызов ? Напрашивается \Classes\Application\closingDown |
|