Історії про дані: випадок з нестандартними індексами

Відео: Иван Васильевич меняет профессию (HD)

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

Мене часто запрошують в программотехнических компанії для надання допомоги у вирішенні проблем блокувань в додатках. Зазвичай фахівці говорять, що потребують допомоги в зв`язку з блокуваннями, але незмінно з`ясовується, що у них відбуваються взаимоблокировки. Спроби зниження числа взаімоблокіровок часто зводяться до скорочення часу, протягом якого здійснюються блокування, і до зменшення обсягу заблокованих даних. Мій досвід показує, що займатися вирішенням проблеми блокувань немає сенсу до тих пір, поки не підібрані оптимальні настройки для запитів. Коли запити виконуються швидко, майже всі пов`язані з блокуваннями неполадки зникають.


Належне індексування - ключова ланка в справі вирішення всіх проблем, пов`язаних з блокуваннями. Важливо зробити так, щоб система SQL Server могла отримати бажаний результат, блокуючи мінімальний обсяг ресурсів.

Поясню цю думку на прикладі. Опублікований в лістингу код формує таблицю, яку ми будемо використовувати при тестуванні.

Якщо ми будемо оновлювати стовпець PrimaryContact за допомогою первинного ключа, обсяг заблокованих ресурсів буде мінімальним:

BEGIN TRAN-UPDATE dbo.CustomersSET PrimaryContact = N`Freddie Mercury`WHERE CustomerID = 3

Я зазначив, що мій сеанс - session_id 53, і можу тепер перевірити (в іншому вікні запиту) блокування, які зберігаються при використанні оновлення (див. Екран нижче).

SELECT resource_type, request_mode,
request_type, request_status
FROM sys.dm_tran_locks WHERE
request_session_id = 53;

Як і у всіх випадках підключення до цієї бази даних, ми зберігаємо спільно використовувану розблокувати базу даних. Оскільки оновлюється конкретний ключ, ми зберігаємо намір блокувань на найвищих рівнях об`єкта, потім на рівні сторінки і, нарешті, ми зберігаємо ексклюзивну блокування на рівні ключа. Намір блокування являє собою розміщуються на більш високому рівні вказівки на те, що ініціатива блокувань зародилася на більш низькому рівні.

Тепер давайте створимо індекс, що включає стовпець PrimaryContact, і додамо включений стовпець PhoneNumber:

CREATE INDEXIX_dbo_Customers_PrimaryContactON dbo.Customers (PrimaryContact) INCLUDE (PhoneNumber) -GO

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

BEGIN TRAN-UPDATE dbo.CustomersSET IsReseller = 0WHERE CustomerID = 3

Але якщо виконується нами оновлення включає в себе хоча б один зі згаданих стовпців індексу, блокування ускладнюється, тому що тепер нам доводиться мати справу і зі сторінками індексів (див. Екран нижче).

BEGIN TRAN-UPDATE dbo.CustomersSET PrimaryContact = N`Freddie Mercury`WHERE CustomerID = 3

Відео: Емі Кадді: Мова тіла формує вашу особистість

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

---