Я столкнулся с проблемой, когда никакие запросы не могли быть выполнены вообще для одной таблицы в нашей базе данных. Стол был в полном тупике. Я проверил sp_whoisactive для ответов и нашел следующее.
Простой SELECT для этой таблицы с идентификатором сеанса 172 ожидал запроса DELETE для этой таблицы с идентификатором сеанса 478, который ожидал INDEX REORGANIZE для этой таблицы с идентификатором сеанса 207, который был ожидание простого SELECT в этой таблице с идентификатором сеанса 598.
После сеанса убийства 598 все сразу завершается. После этого выполнение того же запроса, который удерживал таблицу в тупике в отдельном окне в SSMS, заняло всего 2 секунды. Я спросил вокруг, и этот запрос выполняется в файле Excel. По-видимому, у нас есть множество файлов Excel, которые запускают запросы к нашей базе данных SQL. Очевидно, что это крайне плохая практика, поскольку строку подключения можно найти внутри, но, как и в случае со всем устаревшим, так оно и есть до тех пор, пока не будет исправлено.
При поиске в Google я нахожу лот из ресурсов о Excel фактически блокирующих таблицы. Теперь, насколько мое ограниченное понимание блокировок идет, если запрос, выполненный сессионным идентификатором 598, фактически заблокирует таблицу, он должен делать это только на время запроса. А поскольку выполнение запроса по отдельности заняло всего несколько секунд, я не понимаю, как он выполнялся более 12 часов. Если я могу доверять результатам sp_whoisactive, это не ожидало ничего другого. Так почему же он не завершился?
Прежде чем я предложу что-то вроде добавления WITH(NOLOCK) к каждому запросу в файлах Excel, что является просто исправлением, а не решением, я хотел бы выяснить, почему это произошло, чтобы мы могли избежать этого в будущем. Что вызывает такую тупиковую ситуацию и как ее избежать?