Що робити, якщо якийсь сеанс наклав блокування і заважає всім працювати? Як з'ясувати, який сеанс необхідно вбити, щоб проблема пішла? Така проблема для адміністраторів досить поширена, але з незрозумілих для мене причин в інтернеті я не зміг знайти типового рішення даної проблеми. А воно є!
Днями на роботі зіткнувся з проблемою блокувань, а саме стало з'являтися повідомлення "Конфлікт блокувань при виконанні транзакції. Перевищено максимальний час очікування надання блокування".
Очевидно, що тут немає проблеми взаімоблокіровок, тут просто якийсь сеанс поставив блокування і "забув" прибрати. При цьому проблема загрожувала серйозними наслідками - не проводився документ Реалізації товарів і послуг. У базі одноразово працює близько 100 чоловік, і неможливо виконати типову і часту операцію!
Рішення було два - перезавантаження сервера або пошук збійного сеансу. Перше рішення просте і швидке, але, як тут вже хтось писав - ребутать сервер можна до тих пір, поки тебе не звільнять. Вирішив піти по другому шляху.
Знайшов статтю, як подивитися, що заблоковано через SQL Trace. Так навіть якщо знайду, далі що? Мені потрібен сеанс!
Ближче на 16.00, коли я зрозумів, що далі тягнути не можна, я зробив ребут. У надії, що такого більше не повториться (а це був перший випадок за півроку роботи), зітхнув з полегшенням, все запрацювало. А даремно. Другий день - та ж ситуація. Копався години півтори, знову незрозумілі спроби гуглити та інше. Без результатів. Ребут. Під кінець дня відбулося ще раз. Ну, думаю, чудово, спокійно приїду додому і посиджу, поколупатися. Приїжджаю додому, все вже нормально. Сумно.
На третій день глянув вебінар, розповіли про цікавий і ефективний спосіб пошуку проблеми. Запам'ятав, але проблема більше не виникала. Минув тиждень і ось воно - знову блокування! Потирають руки і починаю діяти.
Копіюємо файл техжурнала в відведене місце, летимо в програму, викликаємо блокування, отримуємо повідомлення і прибираємо або перейменовуємо файл техжурнала. Нам же не потрібні тонни інформації про інших блокування!
Переходимо в папку rphost_PID, знаходимо текстові файли і робимо пошук за словом TTIMEOUT. Бачимо рядок:
До слова, папок rphost_PID може бути кілька, все залежить від того, скільки робочих процесів запущено на сервері.
А далі все просто: дивимося в кінець рядка - WaitConnections = 8239, це наш номер З'ЄДНАННЯ. Заходимо в консоль сервера, переходимо в Сполуки, знаходимо цей номер і дивимося номер сеансу. У моєму випадку на одного користувача було два сеанси - зіпсований і якийсь інший. Гримнув сеанс, на який вказував техжурнал. І о диво! Все запрацювало, радості немає меж! Але, як з'ясувалося пізніше, сеанс не була завислий :), в ньому працювали. Тому на майбутнє - бажано зв'язуватися з користувачем і попереджати.
На мій погляд, досить типове рішення досить типовий проблеми. Невідомо, чому воно мені не попалося, можливо через те, що доводилося його шукати по тривозі, а коли користувачі не підганяли, то і тести проводити не виходило - помилки ж немає.