SQL Server - Почему мой SPID был бы “ПРИОСТАНОВЛЕН”, но не заблокирован при создании индекса?
Лично, я выбрал последовательный подход через языки: Я делаю if (var) (или эквивалентный), только если var объявляется как булевская переменная (или определяется как таковой в C, у нас нет определенного типа). Я даже снабжаю префиксом эти переменные b (таким образом, это было бы bVar на самом деле) быть уверенным, что я не буду случайно использовать другой тип здесь.
мне действительно не нравится неявный кастинг к булевской переменной, еще меньше когда существуют многочисленные, сложные правила.
, Конечно, люди не согласятся. Некоторые идут дальше, я вижу if (bVar == true) в коде Java на моей работе (слишком избыточный для моего вкуса!), другие любят слишком много компактного синтаксиса, идя while (line = getNextLine()) (слишком неоднозначный для меня).
2 ответа
select *
from sys.dm_exec_requests r
join sys.dm_os_tasks t on r.session_id = t.session_id
where r.session_id = <spid of create index>;
Это покажет не только статус запроса, но также все задачи, порожденные запросом. Интерактивный CREATE INDEX может порождать параллельные потоки и приостанавливать себя, пока они не закончатся.
Команда завершена, и соединение ожидает следующей команды.
Из URL: «Эта проблема такая же старая, как SQL Server. Фактически, она восходит к временам Sybase, но продолжает вводить в заблуждение и озадачивать администраторов.
Сеанс с таким статусом команды ожидания / ожидания - это просто клиентское соединение без активного запроса к SQL Server. В таблице ниже показаны переходы из рабочего состояния в спящий для сеанса »