У статті пропонуються важливі поради щодо уникнення тупикових ситуацій SQL Servers
хоча SQL Server протягом останніх кількох років спостерігається величезна еволюція, користувачі все ще регулярно стикаються із ситуацією тупикових ситуацій. В ідеалі сервер баз даних повинен мати можливість отримувати кілька запитів, але це часто призводить до блоків. Конфлікти, коли один процес очікує випуску іншого ресурсу, називаються блоками. А ще є тупикові ситуації.
Уявіть ситуацію, коли одна людина просить другу випустити ресурс, а друга чекає, коли перша випустить. Як результат, обидва застрягли в тупиковій ситуації. Жоден із процесів не може продовжуватися, оскільки обидва заблоковані і вимагають від іншого звільнення ресурсу або блокування.
Під час роботи з SQL servers, тупикові ситуації є досить поширеними явищами, і вони можуть ускладнити весь процес. Неможливо уникнути взагалі безвихідних ситуацій, але можна, безсумнівно, звести до мінімуму шанс створити глухий кут.
Тупикова проблема
Перш ніж перейти до порад щодо мінімізації блокувань, давайте коротко розглянемо деякі з найімовірніших причин їх виникнення. SQL serverСистеми розробляються для автоматичного виявлення блокувань, але якщо про них повідомляється, адміністратори баз даних повинні спробувати зрозуміти причину блокування. Найпоширенішою причиною є поганий дизайн бази даних, без належної перевірки та тестування, а також відсутність індексації. Деякі блокування також виникають через погано розроблені запити.
Слід зазначити, що тупикові ситуації безпосередньо впливають на продуктивність і можуть зупинити обробку бази даних.
1. Зберігайте замовлення однаковим
Взаємоблокування неминуче виникають, якщо ресурси не обробляються у чітко визначеному порядку. Щоб мінімізувати взаємоблокування, усі одночасні транзакції повинні отримувати доступ до об'єктів у чітко визначеному порядку. Адміністратори баз даних повинні розробити чіткий набір правил доступу до об'єктів бази даних. Зазвичай монітори блокувань виконують перевірку взаємоблокувань, і коли вони виявлені, вони вибирають одну жертву взаємоблокування та скасовують її транзакцію. Таким чином, усі блокування знімаються, і попереднім сеансам дозволяється продовжувати процес. Жертви взаємоблокувань вибираються на основі пріоритету взаємоблокування, встановленого сервером, або вартості відкоту.
2. Обмеження під час транзакції
Ви можете заборонити користувачам вводити будь-які типи даних під час обробки транзакції, і ви можете оновити дані до транзакції, щоб уникнути тупикових ситуацій. Крім того, намагайтеся звести взаємодію користувача на мінімальному рівні, оскільки це впливає на швидкість. В ідеалі транзакції повинні бути короткими та швидкими, щоб уникнути тупикових ситуацій. Додаток повинен бути розроблений таким чином, щоб він захопив замки за найменший необхідний час і звільнив їх якомога швидше.
3. NOLOCK Підказка
Коли хтось запускає запит до таблиці на рівні ізоляції за замовчуванням SQL, таблиця блокується, і наступні запити повинні чекати випуску. Підказка NOLOCK корисна в таких ситуаціях, оскільки дозволяє замінити блокування таблиці, а інші запити отримують легкий доступ.
4. Використовуйте пов’язані зв’язки
Якщо одна і та ж програма може відкрити два або більше з'єднання, які можуть співпрацювати між собою, то це не створить тупикових ситуацій. Ось чому рекомендується використовувати зв’язані зв’язки.
Тупикові ситуації - не єдині клопоти, з якими ви можете зіткнутися під час роботи над SQL Server база даних. Насправді випадки sql корупція частіше заподіюють вам горе. Щоб уникнути сценарію втрати даних, інвестуйте в такий потужний інструмент відновлення, як DataNumen SQL Recovery.
Вступ автора:
Віктор Саймон - фахівець з відновлення даних у DataNumen, Inc., яка є світовим лідером у галузі технологій відновлення даних, в тому числі відновлення mdb - - та програмні продукти для відновлення sql. Для отримання додаткової інформації відвідайте https://www.datanumen.com/