Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Может ли запрос с одним и тем же планом выполнения создавать деадлок?
|
|||
|---|---|---|---|
|
#18+
МуМуНе секрет, что некоторые запросы могут приводить к деадлокам. Не секрет, что ВСЕ запросы на обновление данных в конкурентной среде доступа неизбежно будут приводить к дедлокам. И это то, с чем нужно смириться, принять и простить. И соломки заранее подстелить в том месте, где все будет падать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2018, 14:34 |
|
||
|
Может ли запрос с одним и тем же планом выполнения создавать деадлок?
|
|||
|---|---|---|---|
|
#18+
Andy_OLAPМуМуНе секрет, что некоторые запросы могут приводить к деадлокам. Не секрет, что ВСЕ запросы на обновление данных в конкурентной среде доступа неизбежно будут приводить к дедлокам. И это то, с чем нужно смириться, принять и простить. И соломки заранее подстелить в том месте, где все будет падать. В нормально спроектированной системе с нормальными запросами дедлоков не бывает НИКОГДА ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2018, 16:30 |
|
||
|
Может ли запрос с одним и тем же планом выполнения создавать деадлок?
|
|||
|---|---|---|---|
|
#18+
aleksrovAndy_OLAPпропущено... Не секрет, что ВСЕ запросы на обновление данных в конкурентной среде доступа неизбежно будут приводить к дедлокам. И это то, с чем нужно смириться, принять и простить. И соломки заранее подстелить в том месте, где все будет падать. В нормально спроектированной системе с нормальными запросами дедлоков не бывает НИКОГДА Это так. А далее бывает такая ситуация, что к одной и той же БД обращаются две разные нормально спроектированные системы. И первую корячить нельзя, и вторая делает то, что теперь нужно. И получаются два апдейта на одних и те же таблицах одной и той же БД. А так, да - обе спроектированы нормально, только вот друг о друге знают многое, но далеко не всё. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2018, 17:18 |
|
||
|
Может ли запрос с одним и тем же планом выполнения создавать деадлок?
|
|||
|---|---|---|---|
|
#18+
aleksrovВ нормально спроектированной системе с нормальными запросами дедлоков не бывает НИКОГДА И при этом совершенно не требуется подсказок, смены уровня изоляции или отключения эскалации? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2018, 18:58 |
|
||
|
Может ли запрос с одним и тем же планом выполнения создавать деадлок?
|
|||
|---|---|---|---|
|
#18+
Andy_OLAP, Какие то категоричные ответы. Я не знаю про внутреннее устройство движка MSSQL, могу лишь догадываться, поэтому и спрашиваю, интересуюсь скорее. Я понимаю что клиента(приложение) пишет разработчик каждый по своему, я понимаю про упорядоченное обращение к ресурсам. Когда сервером выступает "СЕРВЕР" с большой буквы - он может решать в каком порядке чего обрабатывать. Если мы говорим про вычитку А-Б,Б-А то да. Вопрос про одни и те же алгоритмы, запросы одним батчем, select-update. Когда начинается эта неопределённость?(параллелизм, кучи не упорядочные, случайная эскалация и т.п. ) Вопрос мой был сформулирован был не точно, давайте я его сформулирую более корректно позже с практическими примерами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2018, 00:24 |
|
||
|
Может ли запрос с одним и тем же планом выполнения создавать деадлок?
|
|||
|---|---|---|---|
|
#18+
Eleanor, Ну так выбор необходимого уровня изоляции мы отнесем к правильно спроектированной и нормальным запросам. У меня 2 обсалютно разных системы, одна не очень нагруженая, вторая примерно несколько сотен запросов в секунду, за два года не было ни одного дедлока. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2018, 06:09 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39641150&tid=1689783]: |
0ms |
get settings: |
11ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
46ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
| others: | 261ms |
| total: | 394ms |

| 0 / 0 |
