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

[sukhanchik]

Цитата:

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

Именно. Программист может полагаться на сборщик мусора, не C++ в конце концов, но чтобы твой код полагался на то что на стороне SQL Server адекватное администрирование и ресурсы, это слишком оптимистично.

Тут палка о двух концах.
Вариант 1. Когда программист не может полагаться на админов.
Вариант 2. Когда программист может полагаться на админов, вплоть до самостоятельного умения обслужить сервер
Если нужно обработать большой объём данных (такое количество данных, обработка которых занимает больше 6 часов (цифра абстрактная и приближена к длительности рабочего дня программиста), то неизбежно приходим к варианту 2.
В этом случае собственно - есть выбор - грузить ли данные в оперативную память (раздувать память, потребляемую AOS / IIS / Batch, используя Set, List и т.п. объекты), либо "променять" оперативную память на временные таблицы и джойнить таблицы уже на уровне СУБД.
Ну и собственно при превышении некоторого порога обрабатываемого объёма данных - уже приходится работать с СУБД и админами СУБД. Так сказать в тесном контакте. Но в этом случае и заказчик обычно понимает и не пренебрегает этой необходимостью.

Поэтому временные таблицы и постоянные в роли временных - достаточно неплохо выполняют свою роль. И как-то лично мне последнее время "везёт" на вопросы оптимизации БД. Собственно, поэтому я и ратую за TempDB, после того, как столкнулся с достаточно большим потреблением памяти AOS при использовании List / Set и прочих классов, которые генерируются в оперативной памяти

[ax_mct]

Цитата:

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

Тут палка о двух концах.
Вариант 1. Когда программист не может полагаться на админов.
Вариант 2. Когда программист может полагаться на админов, вплоть до самостоятельного умения обслужить сервер

Вариант 2, он даже на AX2012 крайне редок к примеру на британском рынке.
Я бы и рад контролировать сервер баз данных, но это очень не принято в больших компаниях. Более того вообще другая организация может отвечать за СУБД. То есть полное разделение кода от данных

А с облачным D365FO когда Azure DB и в руках блаженных, то какой тут Вариант 2.

Вариант 1 это на мой взгляд 90% рынка. Когда программист даже не знает кто или что за базу отвечает. Необходимости взаимодействия никто даже и не поймет.

Цитата:

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

ратую за TempDB, после того, как столкнулся с достаточно большим потреблением памяти AOS при использовании List / Set и прочих классов, которые генерируются в оперативной памяти

Если есть время то любопытно
-насколько это критично?
-сколько памяти на AOS?

[sukhanchik]

Цитата:

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

Если есть время то любопытно
-насколько это критично?
-сколько памяти на AOS?

Не.... тут всё не так
Задача: Сделать начальную заливку данных (точнее - подготовиться к этому). При этом многие данные для перелива большие (накладные / заказы за период и т.д.) в части количества записей, поэтому начинаем пробовать на некоторых справочниках, где количество записей условно небольшое (1,3 млн). При этом все понимают, что период заливки будет достаточно большим и после заливки скорее всего придется подгружать свежие данные. При этом во время заливки могут быть те или иные ошибки (в данных), которые хочется подправить и продолжить заливку с того места, где возникла ошибка, а не перезапускать всю процедуру заново.
Если во время процедуры заливки будет падать АОС, Windows и т.д., то также не хочется запускать всё заново, а хочется продолжения работы с того же места.

В процессе программирования и прогона - запускается процедура переливки. Пока она идет - можно смотреть в БД и с удовольствием смотреть на увеличивающееся количество записей в нужных таблицах. Параллельно смотреть на ресурсы сервера - если идет "упор" в диски - анализировать БД и индексы. Если увеличивается объем памяти, потребляемый АОСом - то анализировать причины в т.ч. Trace Parser-ом.

Ситуация. Вижу, что АОС после запуска процедуры переливки начинает достаточно быстро отбирать гигабайты памяти (условно - пусть он "отъел" с 8 до 20 Гб). При этом записей создалось несравнимо мало. Стопаю пакетник, иду разбираюсь. Вижу, что есть цикл, который перебирает записи и формирует List из некоторых записей (отобранных кодом). Позже вижу, что этот перечень используется для формирования данных в других таблицах. Возникает 2 мысли:
- а почему бы просто не перебрать эти записи через Query ?
- а почему бы не складировать RecId отобранных записей в TempDB-шную табличку, а потом ее приджойнить для выборки ?
Но для начала отключаю формирование List-а. Перезапускаю процедуру и вижу, что потребление памяти становится медленнее.

Также замечаю, что есть код, где в цикле создаются новые экземпляры классов. Перестраиваю код так, чтобы этого не было. Чтобы классы создавались либо до цикла, либо уже в методах в локальных переменных, которые вызываются из цикла.
Это еще снижает скорость потребления памяти.

Цель всей этой работы - гарантированно перелить начальные данные в час Х, когда по сути будет условно одна попытка
Поэтому тут нет конкретных цифр, но хочется исключить всякие сюрпризы в т.ч. от переобъевшегося АОСа. Ну и конечно - задача максимально сократить общее время на перелив.

[ax_mct]

Цитата:

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

Не.... тут всё не так
Задача: Сделать начальную заливку данных (точнее - подготовиться к этому).
...
- а почему бы просто не перебрать эти записи через Query ?
- а почему бы не складировать RecId отобранных записей в TempDB-шную табличку, а потом ее приджойнить для выборки ?

Цель всей этой работы - гарантированно перелить начальные данные в час Х, когда по сути будет условно одна попытка
Поэтому тут нет конкретных цифр, но хочется исключить всякие сюрпризы в т.ч. от переобъевшегося АОСа. Ну и конечно - задача максимально сократить общее время на перелив.

То что можно управлять TempDB lifetime через dispose() - это все меняет. Посмотрю как много и как именно используются TempDB в D365FO и если достаточно много то буду использовать.

Спасибо за обьяснение!

[Logger]

Цитата:

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

То что можно управлять TempDB lifetime через dispose() - это все меняет.

Да возможность классная. Но все же это баг.
В X++ и в CIL ресурс освобождается при обнулении счетчика ссылок (только в x++ почти сразу а в CIL когда руки дойдут). Поэтому нигде в X++ мы не увидим в конце метода принудительного вызова dispose или finalize (за очень редким исключением). Правильнее было бы также сделать и с времянками. По дефолту освобождать ресурс при обнулении ссылки. А если где нужно поведение времянок как сейчас, то никто не мешает сохранить ссылку на переменную в глобалкеш, чтобы не обнулялась ссылка. Тогда и проблем никаких бы не возникало.