SQL Server 2008 R2: розблокуємо проблеми з блокуваннями, Інші СУБД, Бази даних, статті

Усунення неполадок бази даних – заняття для сильних духом, особливо коли мова йде про усунення проблем з блокуваннями. Іноді слон в посудній лавці виявляється шаленим носорогом, тобто начебто дрібна проблема виявляється проблемою, яку доводиться довго і клопітно усувати. В інших випадках ви довго можете не помічати рішення проблеми, що перебуває у вас буквально під носом. Саме так справа йде з SQL Server 2008 R2, Де відому проблему з блокуванням вдається вирішити, просто застосувавши найсвіжіший пакет виправлень або оновлення.


Іноді виконуються в базі даних операції призводять до проблем з короткочасними і звичайними блокуваннями. Блокувань і разблокіровок не уникнути. Вони відбуваються в будь-якій системі управління реляційними базами даних, і SQL Server 2008 R2 не виняток.


Блокування відбувається, коли один сеанс бази даних, або ідентифікатор процесу сервера (SPID), отримує блокування певного ресурсу, а в цей час другий SPID намагається отримати конфліктуючу блокування того ж ресурсу. Як правило, блокування ресурсу не тривають долго.Как тільки перший сеанс звільняє блокування, її може отримати другий SPID, щоб продовжити обробку запиту.


Суворі факти з життя блокувань


В SQL Server 2008 R2 застосовується деталізований підхід до блокування, тобто рівень блокування визначається на основі числа уражених записів і інших виконуються в той момент часу операцій.


За замовчуванням блокування укрупнюються з рівня окремих рядків до цілих сторінок навіть до рівня таблиці з міркувань підвищення продуктивності. Хоча в загальному випадку укрупнення вважається хорошою штукою, воно може створювати проблеми, наприклад, коли один SSID блокує всю таблицю, перешкоджаючи іншому SSID працювати нею.


Можна налаштувати параметри блокування на рівні рядків і сторінок. Такі блокування: дозволені для індексів. SQL Server 2008 R2 також підтримує секціонування таблиць. Так як при секціонуванні дані розбиваються на окремі об'єкти, секціонування таблиць сприяє підвищенню загальної продуктивності.


Тривалість блокувань також визначається типами запитів. Коли в рамках транзакції запит не виконується і не використовуються підказки блокування, блокування для виконання інструкцій SELECT виконуються тільки на час читання ресурсу, але не під час запиту. Блокування для інструкцій INSERT, UPDATE і DELETE зберігаються на весь час виконання запиту. Це допомагає гарантувати узгодженість даних і дозволяє SQL Server відкочувати запити в разі потреби.


Коли запит виконується в рамках транзакції, тривалість блокування визначається трьома факторами:



Короткочасні (locking) і звичайні (blocking) блокування – нормальне явище в реляційних базах даних, але вони можуть погіршувати продуктивність, якщо блокування ресурсів зберігаються протягом тривалого часу. Продуктивність також страждає, коли, заблокувавши ресурс, SPID не в змозі звільнити його.


У першому випадку проблема зазвичай дозволяється через якийсь час, так як SPID в кінцевому рахунку звільняє блокування, але загроза деградації продуктивності залишається цілком реальною. Проблеми з блокуванням другого типу можуть викликати серйозне падіння продуктивності, але, на щастя, вони легко виявляються при моніторингу SQL Server на предмет короткочасних і звичайних блокувань.


Приборкання блокувань


Монітор активності (Activity Monitor) SQL Server допомагає виявляти неполадки з короткочасними і звичайними блокуваннями. Уважно стежте за показниками Wait Time (Час очікування), Wait Type (Тип очікування), Wait Resource (Очікування ресурсу) і Blocked By (Заблоковано) для вказаних у списку процесів.


Більшість інформації про процеси, в моніторі активності береться з наступних динамічних уявлень:



Отримати більш чітку картину короткочасних і звичайних блокувань можна за допомогою подання sys.dm_tran_locks, яке надає інформацію про активні запитах блокування – виконаних і очікують виконання. Подання sys.dm_exec_connections, sys.dm_exec_sessions і sys.dm_exec_requests надають відомості відповідно про активних підключеннях, сеансах і запитах.


Зверніть увагу на подання sys.dm_exec_requests (воно описано детально в бібліотеці MSDN). Запити з станом "sleeping" (призупинення) завершили виконання і, швидше за все, очікують команду від програми. Запити зі станом "Running" (Виконується) або "Runnable" (Готово до запуску) у поточний момент обробляються. Запит зі станом "suspended" (Призупинено) очікує отримання блокування або інша подія.


Стовпець wait_type, як передбачає його назва, повертається тип очікування. Якщо значення більше нуля, SPID знаходиться в стані очікування. За додатковою інформацією слід звертатися до столбцам wait_time і wait_resource. Якщо запит заблокований, в wait_time показана тривалість у мілісекундах. У wait_resource зазначений ресурс, звільнення якого очікує SPID. Зверніть увагу також, що blocking_session_id містить ідентифікатор сеансів, блокуючих запит або від'ємне значення з інформацією про власника заблокованого ресурсу.


Некоректно працюють програми переднього плану можуть створювати різноманітні проблеми з блокуванням. Якщо програма не в змозі належним чином управляти рівнями вкладених транзакцій, може вийти ситуація з блокуванням, в якій тип очікування запиту (wait_type) є нульовим, стан "sleeping", але при цьому число транзакцій (open_transaction_count) не дорівнює нулю.


Швидше за все в додатку передбачено таймаут запиту або ініційована відміна команди без створення необхідного числа інструкцій ROLLBACK і COMMIT. Через це блокування залишаються активними, і інші SPID не можуть отримати їх. SQL Server автоматично такі ситуації не виправляє. Коректна обробка вкладених транзакцій лежить на самому додатку.


Якщо програма не вибирає всі рядки результату, виходить ситуація з блокуванням, в якій тип очікування запиту (wait_type) є нульовим, стан "runnable", але при цьому число транзакцій (open_transaction_count) не дорівнює нулю. Найбільш імовірно, що програма не вибрало всі рядки результатів і залишило блокування таблиці, закриваючи доступ до неї іншим SPID. По можливості додаток потрібно конфігурувати так, щоб воно вибирало всі отримані результати.


В разі проблем на стороні сервера, проблеми з блокуваннями можна вирішувати шляхом створення відповідних індексів у своїх базах даних на SQL Server. Також при необхідності можна підлаштовувати запит. Індекси дозволяють скоротити кількість записів, що використовуються при обробці запиту. Це робиться за рахунок скорочення числа операцій пошуку, які доводиться виконувати ядру бази даних. Для визначення таблиць і стовпців, яким потрібні індекси, використовуйте наступні динамічні уявлення:



Важливо пам'ятати, що індекси можуть сповільнювати операції зміни даних (про що йдеться у статті "

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Метки: , , , , , ,
Рубрики: Інші СУБД

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*