axdaily: SQL temporary tables in AX 2012

[Blog bot]

Источник: http://axdaily.blogspot.com/2011/05/...n-ax-2012.html
==============

In AX 2012 a new type of tables was introduced.


In addition to Regular (permanent) tables and InMemory tables (known as temporary tables in previous versions of AX) we have got TempDB tables - SQL server temporary tables.

I believe thit is the feature that many people expected for a long time. TempDB tables utilize the power of SQL tables - full support of joins, aggregation, indexes, all with great performance, but in the same time they have almost the same scoping mechanism as InMemory temporary tables have.
That simplifies developer's life significantly. There is no more need to be aware of tricks like this or like this.


Источник: http://axdaily.blogspot.com/2011/05/...n-ax-2012.html

[MikeR]

Хотелось бы по подробнее узнать про реализацию InMemory и TempDB. На каком уровне создаются, как хранятся (это еще можно предположить), срок жизни, специфика использования и так далее.

[gigz]

InMemory это точно то же самое, что временная таблица в АХ 2009. Вроде бы ничего там не меняли.

TempDB таблицы хранятся в системной базе данных tempdb на SQL сервере. Создаются при первом обращении к буферу на чтение или запись. Очищаются когда на них нет ссылок (точно так же, как InMemory).

По использованию - TempDB должно быть лучше чем InMemory в большинстве случаев. Так как быстрее и нету специфических приколов характерных для InMemory таблиц. Честно говоря, даже трудно придумать где InMemory будут лучше. Где-нибудь где важно чтоб данные находились на клиенте.

[MikeR]

Непонятно, почему TempDB и в каких случаях лучше?
Что будет с передачей данных таблицы с одного уровня на другой, есть ли сжатие данных при передаче?
Вопросов на самом деле очень много.

[Vadik]

Цитата:

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

Непонятно, почему TempDB и в каких случаях лучше?

Вероятно, за счет

Цитата:

full support of joins, aggregation, indexes

Цитата:

Честно говоря, даже трудно придумать где InMemory будут лучше

Там, где идет интенсивная вставка по одной записи (нет раундтрипов AOS<->DB) и не требуется джойнить таблицу с другими. Ну и обратная совместимость опять же

[belugin]

На доступной мне версии tempdb таблицы не поддерживают метод setTmpData

[oip]

Интересно, почему в доступной бета-версии тип TempDB установлен пока только у четырех таблиц (TmpInventAge, TmpLedgerConsQuery, TmpLedgerConsTrans, TmpNumberSeq)? Все остальные временные таблицы имеют тип InMemory.

[belugin]

Ты проверял скриптом или только по таблицам с префиксом tmp?

[oip]

Действительно... Временные таблицы не только tmp*, но и *tmp, *tmp* и даже совсем без tmp. Какой ужас. Ага, среди всех таблиц InMemory и TempDB вполне себе присутствуют.

[Raven Melancholic]

Цитата:

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

.Временные таблицы не только tmp*, но и *tmp, *tmp* и даже совсем без tmp. Какой ужас.

Не ужас, а последние (по-моему примерно с DAX4) руководящие указания партии и правительства рекомендации BP - не начинать темповые таблицы с Tmp.

[oip]

Посмотрел среди всех таблиц. Все равно подавляющее большинство - это InMemory.

Цитата:

Сообщение от Raven Melancholic

Не ужас, а последние (по-моему примерно с DAX4) руководящие указания партии и правительства рекомендации BP - не начинать темповые таблицы с Tmp.

Не начинать, согласен. В BP написано что-то типа "for temporary tables use infix with Tmp".

[gigz]

Цитата:

Что будет с передачей данных таблицы с одного уровня на другой, есть ли сжатие данных при передаче?

Касательно передачи данных tempdb таблицы ведут себя так же, как и все другие таблицы хранящиеся в БД, тоесть Regular таблицы.

Цитата:

На доступной мне версии tempdb таблицы не поддерживают метод setTmpData

Да, есть такой баг. Но все еще теплится надежда что к релизу его пофиксят. Хотя способ сделать вторую ссылку на временную таблицу есть.

Цитата:

Интересно, почему в доступной бета-версии тип TempDB установлен пока только у четырех таблиц (TmpInventAge, TmpLedgerConsQuery, TmpLedgerConsTrans, TmpNumberSeq)? Все остальные временные таблицы имеют тип InMemory.

Их больше. Но все равно мало. Причина историческая. Просто изначально tempdb таблицы делали намного более урезанными, так что большинство возможностей InMemory таблиц не были покрыты. Потом фичу расширили, но переделывать все таблицы уже не стали. Возможно в следующей версии постепенно будут переделывать.

[S.Kuskov]

Вопрос:

Цитата:

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

Интересно, почему в доступной бета-версии тип TempDB установлен пока только у четырех таблиц (TmpInventAge, TmpLedgerConsQuery, TmpLedgerConsTrans, TmpNumberSeq)? Все остальные временные таблицы имеют тип InMemory.

Ответ. Одна из причин:

Цитата:

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

На доступной мне версии tempdb таблицы не поддерживают метод setTmpData

[gigz]

Цитата:

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

На доступной мне версии tempdb таблицы не поддерживают метод setTmpData

Век живи - век учись. Только что узнал, что оказывается уже сделали новый метод для копирования ссылок - linkPhysicalTableInstance. Даже работает

[fed]

Цитата:

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

InMemory это точно то же самое, что временная таблица в АХ 2009. Вроде бы ничего там не меняли.

А спроси пожалуйста, если можешь, отключили ли они сваппинг временных таблиц на диск ? (Это про который мы здесь рассуждаем). Мне кажется что это ограничение выдумали во времена, когда в среднем на AOS стояло 256-512 мегабайт оперативки, а сейчас там, в среднем 8-16 гигабайт. Так что можно было бы либо снять это ограничение (типа - начинаем сваппить таблицы только если общий объем ВСЕХ таблиц в системе превысил 20% от доступной памяти), либо поднять предельный размер InMemory table до 2 Мегабайт примерно...

[MikeR]

Наверное надо было бы в начале обсуждения добавить слайдик, но уже что вышло то вышло

[gigz]

Цитата:

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

А спроси пожалуйста, если можешь, отключили ли они сваппинг временных таблиц на диск ? (Это про который мы здесь рассуждаем). Мне кажется что это ограничение выдумали во времена, когда в среднем на AOS стояло 256-512 мегабайт оперативки, а сейчас там, в среднем 8-16 гигабайт. Так что можно было бы либо снять это ограничение (типа - начинаем сваппить таблицы только если общий объем ВСЕХ таблиц в системе превысил 20% от доступной памяти), либо поднять предельный размер InMemory table до 2 Мегабайт примерно...

ага, интересно. попробую узнать.

[kashperuk]

Не думаю, что работа временных (InMemory) таблиц изменилась. Так что по прежнему будет на диск сохранятся.
Хотя, на самом деле, логично было бы хотя бы порог увеличить..

[gigz]

сказали следующее:
1) во-первых, вроде бы не 128К, а 32К по дефолту, а потом по 128К инкремент
2) есть свойство Entire table cache size (System administration/Area page/Setup/Server configuration), которое так же должно влиять и на InMemory таблицы.

[Logger]

Цитата:

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

сказали следующее:
1) во-первых, вроде бы не 128К, а 32К по дефолту, а потом по 128К инкремент

А можно уточнить, какой максимальный объем может в памяти жить ? Или теперь он неограничен ? Раньше было так - до 128 кб табличка живет в памяти, а дальше сбрасывается на диск и работа с ней, естественно, резко замедляется (инфа из книжки Понтопиддана Inside DAX4.0). Собственно нас интересует - начиная с какой объема работа с времянкой станет медленной.

P.S. Про инкремент не понял. Он к чему относится ? К памяти в оперативке, которая отводится под времянку ?