Deadlocks 2.0 или с чем ещё можно столкнуться

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

Докладчик: Резник Денис. Работает в компании The Frayman Group на позиции Database Architect. Имеет большой опыт разработки и проектирования решений на базе SQL Server и SQL Azure. Увлекается вопросами оптимизации запросов, масштабирования баз данных, разработкой сложных архитектурных решений и внутренним устройством SQL Server. C 2010 года является Microsoft MVP по SQL Server. Сертифицированный тренер Microsoft. Активный участник юзер-группы UNETA и лидер Kyiv SQL Server User Group. Соавтор книги "SQL Server MVP Deep Dives Vol. 2".

Регистрацияhttps://attendee.gotowebinar.com/register/1310186108285105409

cage-aids
cage-aids
cage-aids
cage-aids