Аннотация:
В этом небольшом Q&A рассматривается «проблема» эскалации блокировок (lock escalation). Слово «проблема» намеренно взято в кавычки, так как на самом деле это никакая не проблема, а достаточно остроумное решение других потенциальных проблем. Сначала я попытаюсь объяснить, что же такое эскалация и для чего она предназначена, а потом будет разобрана реализация эскалации блокировок в Microsoft SQL Server 2000.
Здравствуйте, Иван Бодягин, Вы писали:
ИБ> Статья: ИБ> ИБ> ИБ> Авторы: ИБ> Иван Бодягин ИБ> ИБ> Аннотация: ИБ> В этом небольшом Q&A рассматривается «проблема» эскалации блокировок ИБ> (lock escalation). Слово «проблема» намеренно взято в кавычки, так как ИБ> на самом деле это никакая не проблема, а достаточно остроумное решение ИБ> других потенциальных проблем. Сначала я попытаюсь объяснить, что же ИБ> такое эскалация и для чего она предназначена, а потом будет разобрана ИБ> реализация эскалации блокировок в Microsoft SQL Server 2000.
Давно пора было это дело задокументировать. Только, Вань, я понимаю, что ты мс-сиквел любишь, но уж в такой статье грех был промолчать про реализацию блокировок в других СУБД. Рассказать, как Oracle блокирует, как DB2 (про нее я и сам ничего не знаю), как MySQL, какие проблемы могут возникать при полном отказе от эскалации (про Oracle из того ай-би-эмовского отчета).
И непонятно, почему ты это преподнес как Q&A. Ответы там есть, а вот вопросов я не нашел...
-- Всего хорошего!
-- Alex Alexandrov, e-mail: alex_alexandrov@fromru.com
Posted via RSDN NNTP Server 1.8 beta
It's kind of fun to do the impossible (Walt Disney)
Если число блокировок наложенных одной транзакцией превышает 1250, или число блокировок на один индекс или таблицу больше 765, и если при этом больше сорока процентов памяти доступной серверу используется под блокировки, тогда сервер выбирает наиболее подходящую таблицу и пытается эскалировать блокировки до табличного уровня.
Возникло несколько вопросов:
1) Степень конфликтности транзакций никак не рассматривается?
Т.е пусть для простоты имеется одна табличка по которой бегают наши транзакции, ну пусть в милион записей,
в ней бы смогли разместится около 1000 бесконфликтных транзакций блокирующих каждая по 1000 записей, а если они начнут эскалироваться после 765 строк то сразу начнут грызться между собой.
Если конфликтность не учитывается (а по хорошему еще бы и приоритетность транзакций хорошо бы ввести), то получается, что решение принимается из интересов одной конкретной транзакции, а не из интересов общей производительности сервера, что может привести к неочень хорошим последствиям.
2) Приведенные цифры фиксированы или где то настраиваются? Или это "чисто пример" и они все таки зависят от параметров сервера?
3) Эскалация всегда идет сразу до табличного уровня ("тогда сервер выбирает наиболее подходящую таблицу и пытается эскалировать блокировки до табличного уровня"), или это опять же сказано для примера?
Здравствуйте, alexandrov_alex, Вы писали:
_>Только, Вань, я понимаю, что ты мс-сиквел любишь, но уж в такой статье грех был промолчать про реализацию блокировок в других СУБД.
Ну тут-то как раз не про блокировки вообще, а про отдельный нюанс — эскалацию, которая есть далеко не у всех...
А блокировки вообще — это отдельная пестня. В третьем номере RSDN Mag. за этот год, была большая статья Алексея Ширшева, там довольно подробно разобраны блокировки вообще и MSSQL в частности. (правда местами в несколько странной интерпретации ). Видимо со дня на день эта статья появится на сайте.
В номере, который выйдет сейчас (#5, 2003) будет моя статья про дедлоки, там достаточно большая вводная часть про блокировки вообще, чтобы было понятно о чем речь. (правдя там опять-таки в основном MSSQL)
Но вообще-то да, видимо надо написать что-то такое, всеобъемлющее...
Правда сейчас времени почти нет, Юкон на подходе и надо про него уже чего-нибудь излагать.
А вот ты, кстати, не хочешь, написать фундаментальный труд по основам обеспечения Concurrency в журнальном варианте?
_>Рассказать, как Oracle блокирует, как DB2 (про нее я и сам ничего не знаю), как MySQL, какие проблемы могут возникать при полном отказе от эскалации (про Oracle из того ай-би-эмовского отчета).
Не хотелось лезть в дебри vs., стоит упомянуть тот отчет (который между нами действительно не образец объективности), так только и успевай пригибаться. Да и пора уже начинать небольшие Q&A писать..
_>И непонятно, почему ты это преподнес как Q&A. Ответы там есть, а вот вопросов я не нашел...
Ну, в Q&A вопрос — это же не главное.. У нас все Q&A в виде таких вот небольших заметок.
Да и сам же говоришь:
Давно пора было это дело задокументировать.
Вопрос-то периодически возникает и пора было это дело описать.
Здравствуйте, KisA, Вы писали:
KA>Возникло несколько вопросов: KA>1) Степень конфликтности транзакций никак не рассматривается?
Нет, не рассматривается.
KA>Т.е пусть для простоты имеется одна табличка по которой бегают наши транзакции, ну пусть в милион записей, KA>в ней бы смогли разместится около 1000 бесконфликтных транзакций блокирующих каждая по 1000 записей, а если они начнут эскалироваться после 765 строк то сразу начнут грызться между собой.
Ключевой момент здесь — 40% памяти должны быть отданы под блокировки. Если это так, то да, будет попытка эскалации. Но опять же, если они успели пролезть одновременно, то мешать друг-другу они не будут. Просто периодически будет проводиться попытка эскалации до того момента, пока она не увенчается успехом или не освободиться память отдаваемая под блокировки.
А если одна из транзакций успела захватить всю таблицу, то она отработает быстее, чем в параллели с другими, по причине меньшего resource contention и locking overhead, таким образом конечная скорость будет примерно такой же.
К тому же, тут уже вопрос грамотного построения индексов. Если эти транзакции захватывают 1000 записй не пересекаясь, то пользуясь нужным индексом оптимизатор еще на этапе компиляции запроса будет накладывать страничные блокировки на индекс и проблемы просто не возникнет.
KA>Если конфликтность не учитывается (а по хорошему еще бы и приоритетность транзакций хорошо бы ввести), то получается, что решение принимается из интересов одной конкретной транзакции, а не из интересов общей производительности сервера, что может привести к неочень хорошим последствиям.
Нет, тут-то как раз решение принимается исходя из интересов сервера. То есть в данном случае, интересы самой длинной транзакции, с наибольшим количеством блокировок на одну таблицу, и есть интересы сервера. Так как эта транзакция тормозит все остальные.
KA>2) Приведенные цифры фиксированы или где то настраиваются?
Они фиксированы и настроить их нельзя.
KA>3) Эскалация всегда идет сразу до табличного уровня ("тогда сервер выбирает наиболее подходящую таблицу и пытается эскалировать блокировки до табличного уровня"), или это опять же сказано для примера?
Да, эскалация всегда происходит до табличного уровня.
Стратегия наложения блокировок определяется в два этапа. Сначала на этапе компиляци запроса, тога сервером может быть выбрана любая грануулярность (запись, страница, таблица). Но если в процессе выполнения длинной транзакции с большим количествоб блокировок, пришло много других транзакций, то тогда и производится собственно "эскалация", прямо в ходе выполнения длинной транзакции.
Здравствуйте, Merle, Вы писали:
M> Здравствуйте, alexandrov_alex, Вы писали: M> M> Правда сейчас времени почти нет, Юкон на подходе и надо про него уже M> чего-нибудь излагать. А вот ты, кстати, не хочешь, написать M> фундаментальный труд по основам обеспечения Concurrency в журнальном M> варианте?
Написать-то желание есть жгучее, только время... Ну ты понимаешь. А так, конечно,
на RSDN должен быть этакий Бернштайн в популярном изложении.
M> Не хотелось лезть в дебри vs., стоит упомянуть тот отчет (который между M> нами действительно не образец объективности), так только и успевай M> пригибаться. Да и пора уже начинать небольшие Q&A писать..
Да на самом деле, как форум почитаешь, так понимаешь, что для Q&A и статей — непочатый край работы. По базовым вещам зачастую нет у людей понимания.
M> _>И непонятно, почему ты это преподнес как Q&A. Ответы там есть, а вот M> вопросов я не нашел... Ну, в Q&A вопрос — это же не главное.. У M> нас все Q&A в виде таких вот небольших заметок. Да и сам же M> говоришь:
Давно пора было это дело задокументировать.
Вопрос-то M> периодически возникает и пора было это дело описать.
Ну это уж я попридираться чуток решил...
-- Всего хорошего!
-- Alex Alexandrov, e-mail: alex_alexandrov@fromru.com
Posted via RSDN NNTP Server 1.8 beta
It's kind of fun to do the impossible (Walt Disney)
ИБ>Аннотация: ИБ>В этом небольшом Q&A рассматривается «проблема» эскалации блокировок (lock escalation). Слово «проблема» намеренно взято в кавычки, так как на самом деле это никакая не проблема, а достаточно остроумное решение других потенциальных проблем. Сначала я попытаюсь объяснить, что же такое эскалация и для чего она предназначена, а потом будет разобрана реализация эскалации блокировок в Microsoft SQL Server 2000.
мда еще один Microsoft-взгляд ... хоть бы упомянули откуда проблема и почему подобных остроумных решений ненаблюдается в некоторых субд (к стате MS Voxpro ), еще было бы интересно отличие решения IBM.
Так что в теории нужно дописывать "справедливо для реализаци MS"
Мы уже победили, просто это еще не так заметно...
), еще было бы интересно отличие решения IBM. 