AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX Blogs
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 01.02.2019, 14:28   #41  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от skuull Посмотреть сообщение
Надо проверять больше чем на 1 примере!
Ну если внимательно почитать в посте 2 разных примера(обе сессии обновляют разные строки, размер таблицы большой по сравнению с кол-вом обновляемых данных)

Пример 1 - индекс по полю Field2, update_recordset по поля Field2 и Field3. получаем блокировку (которой не было при select forupdate)

Пример 2 - индекс по полю Field2,Field3 update_recordset первой сессии по полям Field2 и Field3, второй сессии по Field2, Field4 получаем блокировку (которой опять же не было при select forupdate)

Или 2 примера тоже мало? сколько надо?
Если смотреть на примеры из реальной жизни, то я уже приводил ссылку
https://axology.wordpress.com/2013/1...tional-tweaks/
Цитата:
Locking on the InventSumDelta table – additional tweaks - We tried changing the column sequence on the two tables to have Partition and DataAreaId in the beginning, but nothing happened until we disabled the ItemId index too. That had an instant effect and practically removed the deadlock issues immediately.
тут имеем похожую ситуацию как в примере 2. Решается удалением лишнего индекса

Цитата:
Сообщение от skuull Посмотреть сообщение
Так вы реально утверждаете, что стажер после 2 месяцев сможет внятно обьяснить почему ?
Извините, что два раза спрашиваю, но уж хочется понять зачем там этот отсыл к стажёру.
Конечно(но срок был от 2 до 6). если не может объяснить простейшую вещь как он сможет решать реальные проблемы на клиенте где нибудь в сибири?

Цитата:
Сообщение от skuull Посмотреть сообщение
Это не изменит мир, но точно будет быстрее. А зачем делать медленнее если можно быстрее?
Ну так рассуждая можно далеко зайти
  • зачем называть переменную custTable, ведь можно назвать с - код будет быстрее компилиться
  • зачем использовать стандартные методы разноски, ведь можно просто результат записать своим методом прямо в результирующие таблицы, так будет быстрее
  • зачем вообще писать код в АХ, ведь можно сделать хранимую процедуру, так будет еще быстрее
...
Обычно после таких рассуждений после пары месяцев c проблемами производительности у спонсора проекта возникает мысль - "Говорили же друзья, надо было брать SAP"

Последний раз редактировалось trud; 01.02.2019 в 14:45.
Старый 01.02.2019, 15:20   #42  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от skuull Посмотреть сообщение
Так я экспертом в вопросе блокировок не являюсь и считаю что самовыдвигаться в эксперты как-то не очень, хотя есть любители
А если Вы "экспертом по теме блокировок не являетесь", то откуда этой теме 12 Ваших постов (и кажется еще в твиттере сколько-то, но там мне как-то лень считать)?
Может это троллинг был ? Не может такого быть, просто не могу поверить...
За это сообщение автора поблагодарили: skuull (0).
Старый 01.02.2019, 17:00   #43  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от fed Посмотреть сообщение
А если Вы "экспертом по теме блокировок не являетесь", то откуда этой теме 12 Ваших постов (и кажется еще в твиттере сколько-то, но там мне как-то лень считать)?
Денис, пятница же, добрее надо как-то

Цитата:
Сообщение от trud
Пример 1 - индекс по полю Field2, update_recordset по поля Field2 и Field3. получаем блокировку (которой не было при select forupdate)

Пример 2 - индекс по полю Field2,Field3 update_recordset первой сессии по полям Field2 и Field3, второй сессии по Field2, Field4 получаем блокировку (которой опять же не было при select forupdate)
Ну да, блокировки ключа индекса как при update_recordset не происходит, зато блокировка на уже обновленные записи удерживается дольше. Причем если deadlock при update_recordset лечится банальным retry, то с длинной транзакцией бороться уже немного сложнее. Насколько в Вашем сценарии типично конкурентное обновление одних и тех же данных и какой подход в итоге даст лучшую производительность (throughput) - без тестирования заранее сказать нельзя

Я это к чему - нет здесь универсальных рекомендаций и "правильных" решений. Много кто делает "правильно" (по BP или на основе каких-то городских мифов), мало кто проверяет как они работают
__________________
-ТСЯ или -ТЬСЯ ?

Последний раз редактировалось Vadik; 01.02.2019 в 17:03.
Старый 01.02.2019, 17:44   #44  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от Vadik Посмотреть сообщение
Много кто делает "правильно" (по BP или на основе каких-то городских мифов), мало кто проверяет как они работают
Более-менее правильно делают те кто начал с ранних версий. Потому как потом смотрят на дичь в стандартном коде 2012 куда слили левый код как он был и просто не понимают как правильно.

Цитата:
зачем делать медленнее если можно быстрее?
Не надо делать быстрее пока не нужно. Даже если можно

Цитата:
Нельзя жертвовать скоростью в угоду возможным идиотам
Нужно жертвовать. Потому как через пару месяцев смотришь на свой же оптимизированный код полным идиотом
Maintenance comes first. А в оптимизированном коде фиг подебажишь нормально.

Последний раз редактировалось ax_mct; 01.02.2019 в 17:52.
За это сообщение автора поблагодарили: trud (1).
Старый 02.02.2019, 21:24   #45  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Цитата:
Сообщение от fed Посмотреть сообщение
Насколько я понимаю, при указании firstonly еще и AOS занимается оптимизацией всяких своих внутренних буферов и сетевых обменов, поскольку он знает что второй записи не будет.
Вполне возможно, я не в курсе что происходит внутри Аксапты, смотрел со стороны SQL.
Но в данном случае таблица с кэшированием (предположм, что записи в кэше нет), запрос по первичному индексу (ну или для DAX2012 даже если бы просто по уникальному).
Тут Аксапта явно готовилась, анализировала работу с кэшем, и озаботилась тем как его готовить. Логично предположить, что в таком случае и все свои внутренние структуры она подготовила для получения именно одной записи.
Если же, потратив столько сил на анализ кеширования, внутри аксапты для запроса в SQL про это "забыли" и все работает как в остальных случаях, то я разочарован. Так и в Деда Мороза верить перестанешь.
Старый 02.02.2019, 21:46   #46  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Какие такие структуры, как их можно особенно готовить чтобы все быстрее стало, кто что готовил и что забыл ? Где это можно увидеть, померить, понюхать ? Не усложняйте, не вводите новые сущности

При FIRSTFAST ядро делает
X++:
SELECT TOP 1 (TOP 10 / TOP 100 / TOP 1000)
Дальше уже оптимизатор SQL Server-а думает что здесь можно оптимизировать и как. При singletone lookup по первичному ключу - особенно не наоптимизируешь, заранее известно что вернется либо одна запись либо ни одной, с методом доступа в общем тоже все понятно

https://tinyurl.com/yb7her2j
__________________
-ТСЯ или -ТЬСЯ ?

Последний раз редактировалось Vadik; 02.02.2019 в 21:53.
Старый 02.02.2019, 22:37   #47  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Цитата:
Сообщение от Vadik Посмотреть сообщение
Какие такие структуры, как их можно особенно готовить чтобы все быстрее стало, кто что готовил и что забыл ? Где это можно увидеть, померить, понюхать ? Не усложняйте, не вводите новые сущности

При FIRSTFAST ядро делает ...
Так не я про особую обработку TOP1 говорил.
Только, наверное, имеется ввиду не FIRSTFAST, а FIRSTONLY...
Старый 06.02.2019, 13:17   #48  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
По поводу перечисления полей в выборке вчера/сегодня наткнулись в DAX2009 на интересную особенность.
Полтора года работал запрос, в котором джоин по трем таблицам из них у двух есть кэширование (Found и FoundAndEmpty), а у третьей нет. Во всех прямо перечислены поля, включая ту, по которой нет кэширования.
При использовании результатов выборки была ссылка на одно из полей некэшированной таблицы, которого нет в выборке, но все работало пока вчера не включили на этой таблице интекс по RecId (при этом и первичный и кластерный остались старыми).
После включения индекса Аксапта четко стала следовать указаниям по выборке полей, естественно, все сломалось. Пробовали включать/выключать индекс по RecId, действительно все повторяется - без индекса перечисление полей игнорируется, с индексом выбираются только указанные.
Так что, судя по всему, есть случаи когда независимо от кэширования список полей игнорируется.
За это сообщение автора поблагодарили: sukhanchik (2).
Теги
#покормитроля, как правильно, производительность

 

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 20:06.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.