Въпреки че всички знаем, че заключването е от съществено значение за целостта на данните, това не променя факта, че може да бъде сериозен трън в очите ви!
Когато видим блокиране в нашата база данни, често предполагаме, че нещо не е наред – това не винаги е така. Според моя опит по-голямата част от блокирането на SQL Server е законно, но трябва да бъде проучено и разбрано. От друга страна, задръстванията рядко са легитимни! Застойните блокировки се считат за критични в света на SQL Server, тъй като процесите се убиват автоматично, тъй като SQL Server разрешава застой, без да изисква ръчна намеса. Отново, въпреки че са „разрешени“, те определено трябва да бъдат проучени и разбрани.
Има няколко стратегии за проектиране, които могат да помогнат за намаляване на случаите на блокиране и блокиране на SQL Server във вашата база данни:
- Използвайте клъстерирани индекси в таблици с голяма употреба
- Избягвайте SQL изрази с голям брой редове
- Разбийте дългите транзакции на много по-кратки транзакции
- Уверете се, че изразите UPDATE и DELETE използват индекси
- Не планирайте заданията за пакетно актуализиране да се припокриват
- Поддържайте статистиката си актуална
И съм сигурен, че има много повече, но реалността е, че можете да следвате всички най-добри практики, за които се сетите, и все още да имате блокиране и блокиране. Това е така, защото в повечето случаи блокирането е причинено от лошо проектиран код на приложението. (Заешката дупка в дизайна на приложенията:кодиране, изолиране на транзакции и модели на достъп. Но засега нека се съсредоточим върху разследването и разбирането на блокирането и блокирането).
Блокиране и блокиране на SQL сървър
Първото предизвикателство с блокирането и блокирането е да се идентифицира кога и къде се случват, защото обикновено не се съобщават, не се докладват след факта или се разрешават автоматично. За да получите истинско разбиране за това какво се случва във вашата база данни по отношение на блокиране и блокиране, трябва да видите тяхното появяване във времето. Освен това, за да отстраните проблема и да спрете бъдещи събития, трябва да стигнете до основната причина за блокирането - да се въоръжите с информация, която трябва да предадете обратно на разработчиците на приложения и по този начин да сложите край на играта за обвинения между разработчиците и DBA.
Ето защо наистина харесвам анализатора на работното натоварване в облака на прожекторите. Мога да избера времеви диапазон – час, ден или персонализиран диапазон – и да видя Заключване -свързана дейност за този диапазон. Веднага разбирам по-добре какво се случва! Мога да виждам модели на заключване, да сравнявам скоростта на заключване с течение на времето с предходен период от време, да виждам скоростта на блокиране през определен период от време и да преглеждам заключващи KPI, като Изключително заключване, Споделено и Актуализиране.
Така че сега искам да стигна до основната причина – това е мястото, където Дървото на измеренията идва. Мога да направя разбивка и да филтрирам информацията за определен период от време, което ми позволява да видя същата информация в по-дълбоки измерения, като Бази данни , Потребители , Програми и SQL оператори , докато филтрирам „белия шум“, докато вървя – ясно идентифицирайки източника(ите) на моя проблем.
Тук гледам кои Бази данни изпитват най-много блокиране през времевия диапазон:
Сега ще разгледам Потребители в избраната база данни:
След това ще избера да видя списъка с SQL изявления причинява заключване, извършено от избрания Потребител в избраната База данни за посочения времеви диапазон .
Сега виждам всички Заключване свързана информация за избрания SQL оператор .
Така че, ако искате да стигнете до дъното на проблемите си със заключване, блокиране и блокиране, препоръчвам ви да разгледате Spotlight Cloud. Spotlight Cloud улеснява от всякога разследването и разбирането на проблемите със заключването в базата данни и в крайна сметка гарантира, че кодът на приложението ви е без блокиране.
