01.02.2019, 14:28 | #41 |
Участник
|
Ну если внимательно почитать в посте 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.
Цитата:
Цитата:
Обычно после таких рассуждений после пары месяцев c проблемами производительности у спонсора проекта возникает мысль - "Говорили же друзья, надо было брать SAP" Последний раз редактировалось trud; 01.02.2019 в 14:45. |
|
01.02.2019, 15:20 | #42 |
Moderator
|
Цитата:
Может это троллинг был ? Не может такого быть, просто не могу поверить... |
|
|
За это сообщение автора поблагодарили: skuull (0). |
01.02.2019, 17:00 | #43 |
Модератор
|
Цитата:
Цитата:
Сообщение от trud
Пример 1 - индекс по полю Field2, update_recordset по поля Field2 и Field3. получаем блокировку (которой не было при select forupdate)
Пример 2 - индекс по полю Field2,Field3 update_recordset первой сессии по полям Field2 и Field3, второй сессии по Field2, Field4 получаем блокировку (которой опять же не было при select forupdate) Я это к чему - нет здесь универсальных рекомендаций и "правильных" решений. Много кто делает "правильно" (по BP или на основе каких-то городских мифов), мало кто проверяет как они работают
__________________
-ТСЯ или -ТЬСЯ ? Последний раз редактировалось Vadik; 01.02.2019 в 17:03. |
|
01.02.2019, 17:44 | #44 |
Banned
|
Цитата:
Цитата:
зачем делать медленнее если можно быстрее?
Цитата:
Нельзя жертвовать скоростью в угоду возможным идиотам
Maintenance comes first. А в оптимизированном коде фиг подебажишь нормально. Последний раз редактировалось ax_mct; 01.02.2019 в 17:52. |
|
|
За это сообщение автора поблагодарили: trud (1). |
02.02.2019, 21:24 | #45 |
Участник
|
Цитата:
Но в данном случае таблица с кэшированием (предположм, что записи в кэше нет), запрос по первичному индексу (ну или для DAX2012 даже если бы просто по уникальному). Тут Аксапта явно готовилась, анализировала работу с кэшем, и озаботилась тем как его готовить. Логично предположить, что в таком случае и все свои внутренние структуры она подготовила для получения именно одной записи. Если же, потратив столько сил на анализ кеширования, внутри аксапты для запроса в SQL про это "забыли" и все работает как в остальных случаях, то я разочарован. Так и в Деда Мороза верить перестанешь. |
|
02.02.2019, 21:46 | #46 |
Модератор
|
Какие такие структуры, как их можно особенно готовить чтобы все быстрее стало, кто что готовил и что забыл ? Где это можно увидеть, померить, понюхать ? Не усложняйте, не вводите новые сущности
При FIRSTFAST ядро делает X++: SELECT TOP 1 (TOP 10 / TOP 100 / TOP 1000) https://tinyurl.com/yb7her2j
__________________
-ТСЯ или -ТЬСЯ ? Последний раз редактировалось Vadik; 02.02.2019 в 21:53. |
|
02.02.2019, 22:37 | #47 |
Участник
|
Цитата:
Только, наверное, имеется ввиду не FIRSTFAST, а FIRSTONLY... |
|
06.02.2019, 13:17 | #48 |
Участник
|
По поводу перечисления полей в выборке вчера/сегодня наткнулись в DAX2009 на интересную особенность.
Полтора года работал запрос, в котором джоин по трем таблицам из них у двух есть кэширование (Found и FoundAndEmpty), а у третьей нет. Во всех прямо перечислены поля, включая ту, по которой нет кэширования. При использовании результатов выборки была ссылка на одно из полей некэшированной таблицы, которого нет в выборке, но все работало пока вчера не включили на этой таблице интекс по RecId (при этом и первичный и кластерный остались старыми). После включения индекса Аксапта четко стала следовать указаниям по выборке полей, естественно, все сломалось. Пробовали включать/выключать индекс по RecId, действительно все повторяется - без индекса перечисление полей игнорируется, с индексом выбираются только указанные. Так что, судя по всему, есть случаи когда независимо от кэширования список полей игнорируется. |
|
|
За это сообщение автора поблагодарили: sukhanchik (2). |