В SQL Server каждый активный процесс уникально идентифицируется “идентификатором системного процесса” или spid. Этот spid является столбцом идентификатора в таблице master..sysprocesses. Хотя возможно прямое обращение к spid с использованием различных методов, обычно не рекомендуется делать это в нормальной производственной обработке.

Явная реализация базовой архитектуры путем доступа к spid может привести к менее надежному приложению. Управление конкуренцией в пользовательских базах и temdb уже достаточно сложно без добавления блокировки базы данных master. Эволюция параллелизма, пулинга и гранулярности процессов обнаруживает уязвимости в действиях на уровне приложения, основанных на явных ссылках на spid sysprocesses.

Однако есть ситуации, когда необходимо быть осведомленным о spid, особенно для административных и обслуживающих процессов. Например, скрипт конвертации данных или DDL-скрипт может быть заблокирован активным spid, который уже использует “объект”, на который действует скрипт. Восстановление базы данных также может быть заблокировано активным spid в базе данных.

В разработочной среде типично часто воссоздавать базы данных. Это может быть сделано каждую ночь из свежих копий проектов SourceSafe или на основе потребностей разработки. В таких случаях необходимо завершить все активные процессы в базе данных, чтобы удалить существующую площадку.

Один из подходов для достижения этой цели – остановить и запустить SQL Server или операционную систему. Однако это может нарушить работу других важных процессов, выполняющихся на том же компьютере. Другой подход – выполнять SQL Server kill для каждого процесса, использующего базу данных. Автоматизация этого процесса может сэкономить время и позволить его выполниться без присутствия.

В административной подсистеме полезно иметь возможность удалить всех пользователей из любой базы данных. Один из подходов – генерировать и компилировать хранимую процедуру для каждой базы данных, которую нужно администрировать в распределенной среде. Затем эти процедуры могут быть вызваны с административного сервера для удаления всех пользовательских spid из базы данных на любом целевом сервере, выполнив kills из курсора в сгенерированной хранимой процедуре.

Если есть вероятность того, что пользователь получит доступ к базе данных до вызова административной задачи, которая требует ресурс, может быть полезно дополнительно ограничить доступ. В хорошо организованной среде опция базы данных “только для использования dbo” может быть достаточной для обеспечения безопасности. Однако решение этой проблемы конкурентности будет зависеть от конкретной среды.

В SQL Server могут возникать зомби, которые являются процессами, видимыми в sysprocesses, но не выполняющимися. Большинство зомби являются результатом плохого кода или плохого дизайна. Хотя SQL Server 7 реже сталкивается с зомби, чем предыдущие версии, они все же возникают. Чтобы избавиться от зомби, обычно достаточно остановить и запустить SQL Server. Однако некоторые зомби могут препятствовать возможности получить исключительное использование объекта.

Чтобы создать процедуры для уничтожения spid, вы можете скомпилировать хранимую процедуру MakeSpidKiller в административную базу данных. Затем, когда требуется конкретный убийца spid для базы данных, выполните MakeSpidKiller, указав имя сервера и имя базы данных целевой базы данных. MakeSpidKiller скомпилирует хранимую процедуру в административную базу данных с именем ExpungeUsers_[имя сервера]_[имя базы данных].

Могут возникнуть ситуации, когда требуется гранулярность, отличная от “всех пользователей в базе данных”. В таких случаях можно изменить условие where курсора dbuserscursor соответствующим образом. Например, если требуется завершить только задания, принадлежащие определенному пользователю домена, условие where может быть изменено для включения нужных условий.

Как и с любыми инструментами в административной подсистеме, важно изменить убийцу spid в соответствии с конкретными потребностями. В то время как избавление от всех пользователей в базе данных работает для среды, которой необходимо удалить и воссоздать базу данных в ежедневном пакете, это может быть излишним или недостаточным для других сред.

Управление активными пользовательскими заданиями в SQL Server требует тщательного рассмотрения потенциального влияния на общую систему. Понимая концепции и реализуя соответствующие стратегии, администраторы и разработчики могут обеспечить бесперебойную работу своих сред SQL Server.