Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Aggressive Under-Indexing  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7762
ssedov,

с таблицей глобального счетчика иначе нельзя работать - только сериализируемая блокировка. Иначе процессы при одновременном доступе получат/кстановят недостоверные идентификаторы. Разумеется, при этом выстроится очередь доступа к счетчику. Какого-то улучшения можно добиться лишь изменением логики и архитектуры данных.
10 дек 18, 12:25    [21758972]     Ответить | Цитировать Сообщить модератору
 Re: Aggressive Under-Indexing  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4730
ssedov
Гавриленко Сергей Алексеевич,

Проблемы ежедневно практически в одно и тоже время. Количество блокированных процессов вырастает от нескольких сотен, до почти двух тысяч. При этом у пользователей все встаеет, начинаются звонки и жалобы. Порой это чаще, раз 5-10 в день, порой 1 раз или редкие дни что ни разу.
В итоге решили понять в чем причина, так как какой то связи пока проследить не получается. Запустил на день трейс на эскалации и блокированные процессы. На двух таблицах были эскалации, но блокировки возникали на той что привел в первом посте. Поэтому эскалации оставил на потом, считая что дело не в них. Пока решил попробовать разобраться с блокировками.
С бд работают около 10 серверов веб приложения. Через веб подключаются пользователи.
Какая-то ещё нужна информация?


Вот тут самое оно перевести таблицу в InMemory и такое понятие как блокировка вообще исчезнет как класс, но вы версию не указали.
10 дек 18, 13:46    [21759097]     Ответить | Цитировать Сообщить модератору
 Re: Aggressive Under-Indexing  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31355
a_voronin
Вот тут самое оно перевести таблицу в InMemory и такое понятие как блокировка вообще исчезнет как класс, но вы версию не указали.
Ээээ, "исчезнет как класс"?
Блокировка - это не какая то "бага", которую поправили внедрением функционала InMemory, это фцнуциорал СУБД, гарантирующий атомарность изменения данных. Разумеется, для InMemory таблиц блокировки точно такие же, разве что реализованы другим кодом. Иначе были бы перекорёженные записи, где половина полей изменены одним процессом, а половина другим.

ТС нужно просто делать блокировки короче, если это возможно. Например, без внешней транзакции, внутри простого апдэйта.
10 дек 18, 17:40    [21759387]     Ответить | Цитировать Сообщить модератору
 Re: Aggressive Under-Indexing  [new]
invm
Member

Откуда: Москва
Сообщений: 9349
a_voronin
Вот тут самое оно перевести таблицу в InMemory и такое понятие как блокировка вообще исчезнет как класс, но вы версию не указали.
Самое оно - читать вопросы внимательно и думать перед ответом.
Как in-memory поможет ТС'у, у которого конкурентные обновления одной и той же строки?
alexeyvg
Ээээ, "исчезнет как класс"?
Исчезнет. In-memory таблицы lock-free - применяются оптимистические блокировки. Соответственно, при конкурентном изменении одних и тех же строк, возникает конфликт и одна из транзакций откатывается.
10 дек 18, 18:33    [21759446]     Ответить | Цитировать Сообщить модератору
 Re: Aggressive Under-Indexing  [new]
aleks222
Member

Откуда:
Сообщений: 961
[quot invm]
a_voronin
Исчезнет.

In-memory таблицы lock-free - применяются оптимистические блокировки.

Соответственно, при конкурентном изменении одних и тех же строк, возникает конфликт и одна из транзакций откатывается.


Кто на ком стоял?

ЗЫ. Интересно, как "возникает конфликт", если "блокировки нет"?

ЗЗЫ. Тредстартеру In-Memory помогут как мертвому припарки.
10 дек 18, 18:57    [21759472]     Ответить | Цитировать Сообщить модератору
 Re: Aggressive Under-Indexing  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31355
invm
alexeyvg
Ээээ, "исчезнет как класс"?
Исчезнет. In-memory таблицы lock-free - применяются оптимистические блокировки. Соответственно, при конкурентном изменении одних и тех же строк, возникает конфликт и одна из транзакций откатывается.
А, точно.

Просто это как бы базовое ограничение - "необходимо обеспечить атомарность". Так что не поможет, даже можно не читать про InMemory, что бы это понять. А то, что там откатывается, а не ждёт, я не помнил, не работаю с InMemory, но это уже детали
10 дек 18, 19:12    [21759479]     Ответить | Цитировать Сообщить модератору
 Re: Aggressive Under-Indexing  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31355
aleks222
Кто на ком стоял?

ЗЫ. Интересно, как "возникает конфликт", если "блокировки нет"?
Ну, не придирайтесь к словам :-)
Блокировки нет, но ждать прога не будет, просто отвалится с ошибкой.
10 дек 18, 19:19    [21759484]     Ответить | Цитировать Сообщить модератору
 Re: Aggressive Under-Indexing  [new]
invm
Member

Откуда: Москва
Сообщений: 9349
aleks222
Интересно, как "возникает конфликт", если "блокировки нет"?
Тебе уже неоднократно говорилось - если не можешь что-то осознать, то это не означает, что этого не существует.
При должном усердии, сможешь восполнить пробел в знаниях из статей и литературы.
10 дек 18, 19:27    [21759491]     Ответить | Цитировать Сообщить модератору
 Re: Aggressive Under-Indexing  [new]
aleks222
Member

Откуда:
Сообщений: 961
invm
aleks222
Интересно, как "возникает конфликт", если "блокировки нет"?
Тебе уже неоднократно говорилось - если не можешь что-то осознать, то это не означает, что этого не существует.
При должном усердии, сможешь восполнить пробел в знаниях из статей и литературы.


Если чего-то нет - этого нет.

Если конфликт возникает => есть блокировка.

Если гуру называет блокировку неблокировкой - это проблемы гуру.
11 дек 18, 05:17    [21759743]     Ответить | Цитировать Сообщить модератору
 Re: Aggressive Under-Indexing  [new]
invm
Member

Откуда: Москва
Сообщений: 9349
aleks222
Если чего-то нет - этого нет.

Если конфликт возникает => есть блокировка.

Если гуру называет блокировку неблокировкой - это проблемы гуру.
Для желающих поумничать и пожонглировать определениями: если чего-то нет, но некоторым особо одаренным кажется, что оно таки есть, то это проблемы особо одаренных...
11 дек 18, 10:10    [21759879]     Ответить | Цитировать Сообщить модератору
 Re: Aggressive Under-Indexing  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7762
Интересное решение оптимистической блокировки... На разрешение записи оптимистическая предполагает два настраиваемых исхода - ожидание окончания блокирующей вставки или завершение с ошибкой. Вы пишете, что MS использует только вариант с ошибкой?

Основное же назначение оптимистической - это разделить чтение и запись. Для чтения и записи используется версионирование страниц, т.е. читающие процессы используют версию из таблицы, а обновлённые страница попадают в свою версию транзакции. Варианты моменты фиксации, по идее, как описано выше.

Автору версионирование категорически воспрещено. У него, похоже, проблема в том, что эта таблица - счетчик держится транзакциями процедуры, которая массово вызывается, а сами транзакции достаточно длительные, чтобы создавать очередь. Там дело не в таблице, а в архитектуре, создавшей бутылочное горлышко в виду этой таблицы.
11 дек 18, 11:06    [21759965]     Ответить | Цитировать Сообщить модератору
 Re: Aggressive Under-Indexing  [new]
invm
Member

Откуда: Москва
Сообщений: 9349
Владислав Колосов
Вы пишете, что MS использует только вариант с ошибкой?
Вас не смущает, что при варианте с ожиданием будет нарушение уровня изоляции?
11 дек 18, 11:34    [21760009]     Ответить | Цитировать Сообщить модератору
 Re: Aggressive Under-Indexing  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7762
invm,

не пойму вопрос. Откуда появится нарушение?
11 дек 18, 13:15    [21760202]     Ответить | Цитировать Сообщить модератору
 Re: Aggressive Under-Indexing  [new]
invm
Member

Откуда: Москва
Сообщений: 9349
Владислав Колосов,

Изоляция транзакций для in-memory таблиц основана на версиях строк. Самый низкий TIL для таких таблиц - SNAPSHOT.
Следовательно, если реализовать механизм ожидания для конкурентных update'ов, то невозможно гарантировать, что мы изменяем то же самое значение, что было на момент начала транзакции.
11 дек 18, 14:01    [21760297]     Ответить | Цитировать Сообщить модератору
 Re: Aggressive Under-Indexing  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31355
Владислав Колосов
invm,

не пойму вопрос. Откуда появится нарушение?
Две транзакции сделали обновление строки, изменили поле field = field + 1

Значение field было равно 100
Каждая транзакция в своей копии строки установила значение поля 101.
Далее первая записала 101, второй что записывать, тоже 101? Это нарушение целостности данных. Потому что выполнение двух запросов field = field + 1 должно увеличить field на 2, а не на 1.
11 дек 18, 14:39    [21760360]     Ответить | Цитировать Сообщить модератору
 Re: Aggressive Under-Indexing  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31355
Владислав Колосов,

https://docs.microsoft.com/ru-ru/sql/database-engine/transactions-in-memory-optimized-tables
11 дек 18, 14:41    [21760364]     Ответить | Цитировать Сообщить модератору
 Re: Aggressive Under-Indexing  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4730
alexeyvg
Владислав Колосов
invm,

не пойму вопрос. Откуда появится нарушение?
Две транзакции сделали обновление строки, изменили поле field = field + 1

Значение field было равно 100
Каждая транзакция в своей копии строки установила значение поля 101.
Далее первая записала 101, второй что записывать, тоже 101? Это нарушение целостности данных. Потому что выполнение двух запросов field = field + 1 должно увеличить field на 2, а не на 1.


Одна транзакция валиться, делает retry, обновляет на 102 . Скажем так, побыстрее это шуршать будет, чем то, что сейчас имеем на физической таблице.
11 дек 18, 14:55    [21760390]     Ответить | Цитировать Сообщить модератору
 Re: Aggressive Under-Indexing  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7762
Спасибо, понятное разъяснение. При оптимистическом накатывании кто последний обновил - тот и прав. Не имеет значения, что было до этого. По крайней мере, я сталкивался с такой реализацией оптимистического обновления в других системах. Это вариант Б, о котором я писал.

Логика понятна в целом - во избежание претензий со стороны эксплуатации лучше перебдеть, чем недобдеть и вариант Б не реализовывать.
11 дек 18, 14:57    [21760395]     Ответить | Цитировать Сообщить модератору
 Re: Aggressive Under-Indexing  [new]
invm
Member

Откуда: Москва
Сообщений: 9349
a_voronin
Одна транзакция валиться, делает retry, обновляет на 102 . Скажем так, побыстрее это шуршать будет, чем то, что сейчас имеем на физической таблице.
О, какая круть.
Оказывается долбать сервер повторами транзакций (причем не важно, что было в этой транзакции до проблемного момента), оказывается выгоднее ожидания блокировки...

Наверное у вас даже есть экспериментальные подтверждения этому?
11 дек 18, 15:23    [21760450]     Ответить | Цитировать Сообщить модератору
 Re: Aggressive Under-Indexing  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31355
a_voronin
alexeyvg
пропущено...
Две транзакции сделали обновление строки, изменили поле field = field + 1

Значение field было равно 100
Каждая транзакция в своей копии строки установила значение поля 101.
Далее первая записала 101, второй что записывать, тоже 101? Это нарушение целостности данных. Потому что выполнение двух запросов field = field + 1 должно увеличить field на 2, а не на 1.


Одна транзакция валиться, делает retry, обновляет на 102 . Скажем так, побыстрее это шуршать будет, чем то, что сейчас имеем на физической таблице.
Разве быстрее второй транзакции делать всё заново, после того, как завершиться первая, чем подождать до конца первой? Ведь ожидание-то одинаковое, в любом случае второй траназкции придётся ждать окончания первой, она же раньше не сможет продолжиться.

Понятно, что в каких то случаях такой алгоритм полезен, иначе зачем его сделали?
Например, в случае достаточно больших обновлений стоимость классического механизма блокировки отдельных строк слишком велика, поэтому происходит эскалация, а из за неё заблокированные транзакции ждут, хотя могли бы не ждать, т.к. они обновляют не те данные, которые затронуты блокирующей транзакцией.

Но в данном конкретном случае выгоды не будет, потому что речь об одной и той же строке таблицы.
11 дек 18, 17:49    [21760648]     Ответить | Цитировать Сообщить модератору
 Re: Aggressive Under-Indexing  [new]
invm
Member

Откуда: Москва
Сообщений: 9349
Владислав Колосов
При оптимистическом накатывании кто последний обновил - тот и прав. Не имеет значения, что было до этого.
При "оптимистическом накатывании" первый и есть последний. Остальные ничего накатить не смогут, ибо данные уже изменены.
11 дек 18, 17:53    [21760651]     Ответить | Цитировать Сообщить модератору
 Re: Aggressive Under-Indexing  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4730
alexeyvg
a_voronin
пропущено...


Одна транзакция валиться, делает retry, обновляет на 102 . Скажем так, побыстрее это шуршать будет, чем то, что сейчас имеем на физической таблице.
Разве быстрее второй транзакции делать всё заново, после того, как завершиться первая, чем подождать до конца первой? Ведь ожидание-то одинаковое, в любом случае второй траназкции придётся ждать окончания первой, она же раньше не сможет продолжиться.

Понятно, что в каких то случаях такой алгоритм полезен, иначе зачем его сделали?
Например, в случае достаточно больших обновлений стоимость классического механизма блокировки отдельных строк слишком велика, поэтому происходит эскалация, а из за неё заблокированные транзакции ждут, хотя могли бы не ждать, т.к. они обновляют не те данные, которые затронуты блокирующей транзакцией.

Но в данном конкретном случае выгоды не будет, потому что речь об одной и той же строке таблицы.


В данном случае надо было задействовать sequence и непонятно почему это было не сделано. Если это невозможно из-за низкой версии, то надо предгенерить значения или использовать очередь в брокере, что возможно уже давно и дает параллельность.
12 дек 18, 12:18    [21761304]     Ответить | Цитировать Сообщить модератору
 Re: Aggressive Under-Indexing  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7762
invm
Владислав Колосов
При оптимистическом накатывании кто последний обновил - тот и прав. Не имеет значения, что было до этого.
При "оптимистическом накатывании" первый и есть последний. Остальные ничего накатить не смогут, ибо данные уже изменены.


Да, это понятно, по варианту А - кто первый встал, того и тапки.
12 дек 18, 13:25    [21761455]     Ответить | Цитировать Сообщить модератору
 Re: Aggressive Under-Indexing  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31355
a_voronin
В данном случае надо было задействовать sequence и непонятно почему это было не сделано. Если это невозможно из-за низкой версии, то надо предгенерить значения или использовать очередь в брокере, что возможно уже давно и дает параллельность.
Да, или IDENTITY
Но это уже другой вопрос.
Может, у них какой то особый алгоритм формирования этого номера, определяемый, скажем, внешними правилами (скажем, государственными нормативными актами, или давно принятыми локальными нормативными актами).
12 дек 18, 16:30    [21761812]     Ответить | Цитировать Сообщить модератору
 Re: Aggressive Under-Indexing  [new]
DaniilSeryi
Member

Откуда:
Сообщений: 1723
alexeyvg
a_voronin
В данном случае надо было задействовать sequence и непонятно почему это было не сделано. Если это невозможно из-за низкой версии, то надо предгенерить значения или использовать очередь в брокере, что возможно уже давно и дает параллельность.
Да, или IDENTITY
Но это уже другой вопрос.
Может, у них какой то особый алгоритм формирования этого номера, определяемый, скажем, внешними правилами (скажем, государственными нормативными актами, или давно принятыми локальными нормативными актами).


Или про identity, @@identity и scope_identity() и не слышали.
12 дек 18, 22:55    [21762222]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить