Sqlserver
 sql >> база данни >  >> RDS >> Sqlserver

Използване на Spotlight Cloud за разрешаване на блокиране на SQL Server

Блокирането на SQL Server в база данни се случва, когато транзакция държи заключване на ресурс и не позволява на една или повече връзки да работят на същия ресурс. Втората връзка трябва да изчака освобождаването на ключалката, преди да може да продължи. Това се прави, за да се гарантира изолиращият компонент на ACID – което означава, че едновременните транзакции не са видими една за друга, докато не завършат. Блокирането в SQL Server може да порази производителността във всяка среда.

Една от задачите, които администраторите на базата данни правят, е да идентифицират заявката, извършваща блокирането, да я отстранят и след това да направят още една стъпка, за да определят основната причина. Проучването на първопричината, особено след факта, може да бъде много трудна задача. За повечето това означава много отнемащ време процес на руутване чрез динамични изгледи за управление на SQL Server, като s ys.dm_exec_requests или изпълняване на системни процедури като sp_who2 за да разберете подробности за идентификаторите на системните процеси (SPIDS), включени в блокчейна. Spotlight Cloud може значително да намали усилията ви да идентифицирате тези блокиращи събития.

Използване на мониторинг на база данни за идентифициране на блокове на SQL сървър

Фигура 1:Табло за управление с общ преглед

Започвайки от таблото за управление с преглед, Spotlight Cloud предоставя ясен изглед на цялата среда. Той показва показатели, включително брой сесии, процеси, използване на паметта, консумация на дискове и изчаквания с един поглед. По-важното е, че ясно показва блокираща активност; в центъра на фигура 1, можете ясно да видите, че в момента има два блокирани процеса.

За DBA навлизането в подробностите е необходимо за разрешаване на проблеми с блокирането. Spotlight Cloud ни дава възможността да разгледаме повече подробности за сесията, като просто изберете падащото меню от Общ преглед, както е показано на Фигура 2.

Фигура 2:Падащо меню от Общ преглед

Spotlight Cloud ви позволява лесно да видите кои сесии са блокирани и какви изявления са включени. На фигура 3 можете да видите, че и двата SPID 59 и 65 са блокирани (обозначени в оранжево осветяване около състоянието), което съответства на блокирания брой. Ще забележите също, че Spotlight Cloud продължава да предоставя обобщени подробности за текущото ни състояние на екземпляра, което ни позволява да следим важни броячи, докато се потапяме в проблемите с производителността.

Използване на мониторинг на Spotlight Cloud SQL Server за разрешаване на проблеми с блокирането

Фигура 3:Табло за управление на сесиите

Таблото за управление на сесиите (както се вижда на фигура 3) ни дава жизненоважна информация, от която се нуждаем, за да разрешим проблема. Тук можете да намерите важна информация като кой потребител изпълнява операторите, коя база данни е засегната и кога е заявена сесията. Дадената дълбочина на детайлите спестява реално време за онези DBA, които се нуждаят от бързи отговори за това какво причинява блокиране, за да могат да го разрешат. Вие не само виждате, че имате два блокирани прехода, но също така можем да видим, че и двете са оператори UPDATE в една и съща таблица, изпълнявани от акаунта на мрежовите услуги срещу базата данни за продажби. Действителното изявление е показано в долния десен ъгъл. И накрая, можем да видим както активния SPID, така и SPID, от който той е блокиран.

Към горния десен ъгъл на фигура 3, в син текст, Spotlight Cloud ви казва къде да продължите по-нататък във вашето разследване. Продуктът във всеки слой дава ясен път как да се гмуркате още по-дълбоко. Щракването върху връзката Разследване в анализатора на работното натоварване ви позволява да видите какво е извикало SPID 61, който се оказва блокер на потенциални клиенти за SPID 65.

Фигура 4:Анализатор на работното натоварване (това е мястото, където искаме да разширим блокираните сесии)

Анализаторът на работното натоварване ви дава разбивка, която ви позволява да навлизате в конкретни ресурси, като блокиране. На фигура 4 можете да видите как се гмуркаме по-нататък, като щракнете върху двете стрелки за разгъване в ъгъла на секцията Блокирани сесии.

Фигура 5:Подробности за блокирани сесии

Сега, когато познавате свързаната база данни, можете да копаете малко по-нататък. В лявата навигация можете да разгледате базата данни за продажби. Тук можете да видите SPID 61 и 64, включително текущото състояние. И двата идентификатора на системни процеси блокират и забележете, че SPID 59 вече е блокиран и от SPID 64. Този изглед помага да се гарантира, че можете да изпреварите блокирането, докато продължавате да разследвате.

В долната половина на фигура 5 можете да видите в картографирането на блокирана сесия, че ви казва подробностите за SPID 61, който в този случай е нашият водещ блокер. Виновникът всъщност е част от работа на SQL агент, която се изпълнява, което има смисъл въз основа на потребителя, който открихме, изпълняващ оператора. Ако си спомняте, това беше акаунтът за мрежова услуга, NT AUTHORITY\NETWORK SERVICE. В този случай услугата SQL Agent работи под този конкретен набор от идентификационни данни.

Следващата стъпка е да разберете какви задачи се изпълняват и да видите дали можете да убиете заданието, за да спрете блокирането. Обикновено ще отидете в SQL Server Management Studio, за да прегледате SQL Agent и да разгледате работните места, но Spotlight ви улеснява и ви дава изчерпателен поглед върху работните места. Можете да намерите това, като щракнете върху стрелката до думите „Анализатор на работното натоварване“ в горната част, точно както направихте, когато навигирате от Общ преглед до Сесии.

Фигура 6:Падащо меню от Workload Analyzer

Предотвратяване на бъдещи блокове на SQL сървър

Проучването на блокирането отнема време и понякога, докато изследваме конкретен проблем, блокирането се решава от само себе си. В този случай изпълняваната задача е завършена и блокираните актуализации са в състояние да се изпълняват. Въпреки че непосредственият проблем вече не съществува, все още трябва да продължите да търсите основната причина, за да сте сигурни, че можете да го предотвратите в бъдеще.

Тъй като вече сте идентифицирали SPID 61 като работата, която се изпълняваше, и тъй като времето е минало, сега ще трябва да погледнете историята. За да прегледате историята, просто променете показания период от време на времевия диапазон на активното блокиране. На фигура 7 можете да видите периода от време в десния ъгъл, можете да щракнете върху падащото меню и съответно да коригирате времената. След това искате да потърсите SPID 61, като използвате функцията за търсене. Всяка среда е различна, така че това, което правите с тази информация, сега ще зависи. Дали ще коригирате времето на заданието, ще направите някои промени в индексите, кода или конфигурациите, зависи изцяло от вас.

Фигура 7 Работни места

Фигура 8:Дълготрайни блокове

Някои блокове просто идват и си отиват толкова бързо, че нямат значителен ефект върху производителността. Когато се задържат по-дълго, трябва да знаем за това бързо. Spotlight Cloud има аларма за „продължително заключване“, която уведомява потребителя за блокове, които не изчезват.

Фигура 9:Измерение на блокиран обект

Блокирането е симптом на някои по-големи проблеми и често са необходими различни гледни точки, за да се стигне до първопричината. Измерението на блокирания обект в анализатора на работното натоварване Spotlight Cloud позволява на потребителя бързо да установи обекти, които генерират най-много блокираща активност за даден екземпляр.

Идентифицирането на блокиране и копаене в причината е най-трудната част за DBA. Spotlight Cloud Professional ни позволява да стигнем до тази информация бързо и ефективно. Когато времето разреши активния проблем, Spotlight Cloud ни позволява да продължим да разследваме, за да стигнем до основната причина и в крайна сметка ни дава информацията, от която се нуждаем, за да вземем информирани решения как да предотвратим бъдещи събития.

Искате ли да видите Spotlight Cloud в действие? Започнете своя безплатен 30-дневен пробен период днес.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. DB_NAME() срещу ORIGINAL_DB_NAME() в SQL Server:Каква е разликата?

  2. Как автоматично да генерирам уникален идентификатор в SQL като UID12345678?

  3. Мога ли да използвам няколко курсора в една връзка с pyodbc и MS SQL Server?

  4. Разлика между sys.views, sys.system_views и sys.all_views в SQL Server

  5. Превръщане на низ, разделен със запетая, в отделни редове