Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Как на 100% избежать мёртвых блокировок
|
|||
|---|---|---|---|
|
#18+
Подскажите, (please! ) как на 100% избежать мёртвых блокировок ? Т.е. как я поняла, если в некоей транзакции я обращаюсь с обновлением к табл. А, затем обновляю табл. В, то и в других транзакциях это делать следует в той же последовательности? Кстати, читала, что SQL-2000 сам отслеживает мёртвые блокировки и откатывает ту транзакцию, которая имеет меньшую цену. Что значит меньшую цену? Словом, есть какое-то золотое правило, как избегать мёртвых блокировок, может примерчик подкинете, а? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2001, 13:37 |
|
||
|
Как на 100% избежать мёртвых блокировок
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2001, 14:49 |
|
||
|
Как на 100% избежать мёртвых блокировок
|
|||
|---|---|---|---|
|
#18+
2 Сашенька: Пример: А) Тут возможна мертвая блокировка: транзакция 1) ..... update table1 set field1=1 update table2 set field2=1 ...... транзакция 2 ...... update table2 set field1=1 update table1 set field2=1 ...... Б) А тут - нет ..... update table1 set field1=1 update table2 set field2=1 ...... транзакция 2 ...... update table1 set field1=1 update table2 set field2=1 ...... Т.е. как Вы и сказали - нужно делать запрос ресурсов в одинаковой последовательности, чтобы не получилось, что одна из транзакций ждет освобождения ресурса (таблицы например), заблокированного второй транзакцией, а вторая в это время ждет освобождения ресурса заблокированного первой. Для установки приоритета транзакции при деадлоке используйте (внутри транзакции) SET DEADLOCK_PRIORITY { LOW | NORMAL | @deadlock_var } Если уровень приоритета двух транзакций попавших в деадлок одинаков, то выбор транзакции для отката будет сделан случайным образом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2001, 11:04 |
|
||
|
Как на 100% избежать мёртвых блокировок
|
|||
|---|---|---|---|
|
#18+
Спасибо всем! И всё же, возможны ещё какие случаи возникновения мёртвых блокировок? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2001, 20:03 |
|
||
|
Как на 100% избежать мёртвых блокировок
|
|||
|---|---|---|---|
|
#18+
При применении хинта HOLDLOCK или увеличении уровня транзакции до повторяемого чтения или сериализации, вероятность получения дидлоков резко возрастает. Другими словами, если не делать ни того, ни другого, а с транзакциями работать аккуратно и только по минимальной необходимости, то беспокоиться о дидлоках скорее всего не придется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2001, 06:40 |
|
||
|
Как на 100% избежать мёртвых блокировок
|
|||
|---|---|---|---|
|
#18+
У нас было и до сих пор появляется некоторое количество deadlock-ов регулярно в старых приложениях. В новых используется явное указание типа захвата, мы используем захват таблицы TABLOCK, например, INSERT имя_таблицы (список_полей) WITH (TABLOCK) - больше информации о deadlock-ах я не встречал в этих приложениях ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2001, 06:56 |
|
||
|
Как на 100% избежать мёртвых блокировок
|
|||
|---|---|---|---|
|
#18+
Еще бы! Вы превратили свою базу в однопользовательскую на запись. Какой дидлок может быть в однопользовательской системе?! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2001, 08:14 |
|
||
|
Как на 100% избежать мёртвых блокировок
|
|||
|---|---|---|---|
|
#18+
Вот и чудно никаких и нет, потому как до этого они сыпались каждые десять минут, нынешняя ситуатция всех вполне устраивает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2001, 14:18 |
|
||
|
Как на 100% избежать мёртвых блокировок
|
|||
|---|---|---|---|
|
#18+
На самом деле - deadlocks - не такая уж и большая проблема. Если после всей оптимизации они все таки возникают - то приложение просто должно обрабатывать ошибку, генерируемую deadlock'ом и попросту перезапускать транзакцию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2001, 05:14 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=32017570&tid=1824881]: |
0ms |
get settings: |
11ms |
get forum list: |
18ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
70ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
| others: | 248ms |
| total: | 412ms |

| 0 / 0 |
