Полезные рецепты с AX Technical Conference 2014

[shogel]

Настоящим открытием для меня стал вот этот "рецент" с сессии "Ask the Experts" : Identifying a user session in SQL Server. Видимо надо чаще заглядывать в technet

p.s.
Со слов Dynamics AX Performance Team - включение этого параметра практически не влияет на производительность.

[Link]

Цитата:

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

Видимо надо чаще заглядывать в technet

Updated: December 12, 2011
Чаще чем раз в три года

[Kabardian]

Цитата:

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

включение этого параметра практически не влияет на производительность.

Тема называется Troubleshooting database performance [AX 2012] и там же указано, что это не "практические не влияет на производительность", а "включение этого параметра немного влияет на производительность, поэтому функциональность отключена по-умолчанию":

Цитата:

because the inclusion of this information has a small effect on performance, the functionality is not turned on by default.

Не рекомендовал бы включение этого параметра на боевой системе, если с производительностью нет проблем. А когда появятся проблемы - можно включить и посмотреть "кто виноват" и "что делать".

[pitersky]

тут ещё вопрос в том, насколько small действительно small
это всяк по-разному понять может

[fed]

Я подозреваю, что весь overhead сводится к посылке одного лишнего SQL-оператора в начале каждой транзакции. (http://msdn.microsoft.com/en-us/library/ms189252.aspx - SET CONTEXT_INFO).
Насколько я знаю, соединения с сервером БД реюзаются между разными пользовательскими сессиями. Когда транзакция начинается - захватывается новое соединение с БД, после того как транзакция завершается - соединение еще сколько-то (кажется 30 для SQL Server) секунд держиться системой для повтороного использования. Соответственно - чтобы контекст установить, достаточно просто выполнять этот оператор в начале каждой транзакции. (Кстати - надо будет попробовать то же самое сделать в DAX2009, засунув соответствующий оператор в ttsNotifyBegin().)

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

[shogel]

Цитата:

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

,,,там же указано, что это не "практические не влияет на производительность", а "включение этого параметра немного влияет на производительность, поэтому функциональность отключена по-умолчанию"

Я процитировал менеджера Dynamics AX Performance Team выступавшего на конференции. Если быть точным, то он сказал, что его группа "не выявила падения производительности при включенном параметре".

Однако я полностью согласен, что срочно бросаться включать "SET CONTEXT_INFO" на рабочем приложении не стоит Например, по словам одного из партнеров, этот параметр может привести к ошибке в работе с ODBC источниками данных.

[Kabardian]

Цитата:

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

никогда не отключаю никакие отладочные галочки на боевых серверах

...ну, там много разных галочек и "никакие" совсем уж категорично звучит, но я понял примерно, что вы имеете ввиду.

В AX 2012 вопреки традиционным заявлениям Microsoft об улучшении производительности, я пока наблюдаю обратную ситуацию - она субъективно по ощущениям стала заметно ниже. Поэтому переживаю как бы не усугубить ситуацию.

Цитата:

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

Я подозреваю, что весь overhead сводится к посылке одного лишнего SQL-оператора в начале каждой транзакции. (http://msdn.microsoft.com/en-us/library/ms189252.aspx - SET CONTEXT_INFO).

А вот это уже интересная деталь, спасибо.

[Ivanhoe]

Сильно замедлился интерфейс. Различные обработки и разноски стали быстрее, особенно в пакетном режиме - в разы.

[Vadik]

Цитата:

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

Например, по словам одного из партнеров, этот параметр может привести к ошибке в работе с ODBC источниками данных.

А может и не привести.. Включил месяц назад на пробу, выключать не планирую. DMF с ODBC источниками данных работает как и прежде

UPD 2015.04.09 - Перестают работать 'не MS SQL' (не T-SQL) источники (например, Oracle)