INF: Descripción de cómo el Transact-SQL KILL, comando funciona

Exención de responsabilidades de contenido KB retirado

Este artículo se refiere a productos para los que Microsoft ya no ofrece soporte técnico. Por tanto, el presente artículo se ofrece "tal cual" y no será actualizado.

Resumen

El comando KILL de Transact-SQL se utiliza para terminar repentinamente un proceso de SQL Server. Cada proceso se denomina a menudo un identificador de proceso del sistema (spid). El botón de proceso de interrupción de SQL Enterprise Manager en actividad actual simplemente envía un comando KILL de Transact-SQL al servidor, por lo que el mecanismo de interrupción del servidor en este caso es el mismo.


Un spid puede responder al comando KILL inmediatamente, o después de un retraso o no en todos. Un comando KILL retardado o sin respuesta puede ser normal en algunas condiciones. Este artículo describe cómo funciona el comando KILL, ¿cuáles son estas condiciones retrasadas o la falta de respuesta y cómo identificarlos.
Nota: Este artículo describe un comando DBCC (DBCC PSS) que no es compatible y puede causar un comportamiento inesperado. Microsoft no puede garantizar que pueda resolver los problemas resultantes del uso incorrecto de este comando DBCC. Utilice este comando DBCC bajo su propio riesgo. Este comando DBCC no esté disponible en versiones futuras de SQL Server. Para obtener una lista de los comandos DBCC admitidos, vea el tema "DBCC" en la sección de referencia de Transact-SQL de los libros en pantalla de SQL Server.

Más información

Cada conexión de base de datos constituye una fila en sysprocesses, a veces denominado un spid o proceso del sistema Id. En la terminología de SQL Server, cada conexión también se denomina un "proceso", pero esto no implica un contexto de proceso independiente en el sentido habitual. En SQL Server 6.0 y 6.5, cada proceso equivale aproximadamente a y atendidas por un subproceso independiente del sistema operativo. Cada conexión de base de datos también está formado por las estructuras de datos de servidor que realizar un seguimiento de estado de proceso, estado de la transacción, los bloqueos mantenidos y así sucesivamente. Una de estas estructuras se denomina el proceso Status Structure (PSS), de los cuales hay uno por cada conexión. El servidor examina la lista de PSSs para materializar la tabla sysprocesses virtual. La CPU y physical_io columnas de sysprocesses se derivan de los valores equivalentes en cada PSS.


El comando KILL de Transact-SQL publicaciones que un "matarse" mensaje a la estructura de ranuras de proceso del spid. Aparece allí como un bit de estado que el spid interroga periódicamente. Si el spid está ejecutando una ruta de acceso del código no interrogar el campo estado PSS, no se produce la interrupción. Algunas condiciones conocidas donde puede producirse esta situación se muestra a continuación. La mayoría de estos se considera el comportamiento esperado y no se considera errores.

SPID está esperando una E/S de red

Si el cliente no recupera todas las filas de resultados, finalmente se forzará el servidor debe esperar cuando se escribe en el cliente. Esto se ve como un sysprocesses.waittype de 0 x 0800. Durante la espera en la red, no de SQL Server que se ejecuta código que puede interrogar el PSS y detectar un comando KILL. Si el spid mantiene bloqueos antes de esperar en la E/S de red, éste podría impedir que otros procesos.


Si la conexión de red el tiempo de espera o se cancela manualmente, el subproceso SQL que se espera en la red de que i/OS tendrán un error devuelto, así que se liberan hasta analizar su PSS y responder a una interrupción. Puede cerrar manualmente una conexión de canalizaciones con nombre con la sesión de red o el comando NET FILES o comando equivalente del administrador del servidor. Otras sesiones IPC, como IPX/SPX y TCP/IP no se puede cerrar manualmente y la única opción en este caso es ajustar el tiempo de espera de sesión para el IPC determinado a un valor más corto. Para obtener más información, consulte el artículo siguiente en Microsoft Knowledge Base:

137983 : cómo solucionar problemas de conexiones huérfanas en SQL Server


El Spid está deshaciendo (también llamado está "en recuperación")

Si la transacción se cancela por cualquier motivo, debe revertir. Si es una transacción de larga duración, puede tardar hasta deshacer como para aplicar la transacción. Esto incluye transacciones de larga ejecución implícitas como único instrucciones SELECT INTO, DELETE o UPDATE. Mientras está deshaciendo no pueden ser sacrificado; de lo contrario, los cambios transaccionales no se copian constantemente.


El escenario de reversión unkillable a menudo puede identificarse mediante la observación de la salida de sp_who, lo que puede indicar el comando ROLLBACK. En la versión de SQL Server 6.5 Service Pack 2 o posterior, un estado de restauración ha sido agregado a sysprocesses.status, que también aparecerán en la salida de sp_who o el Administrador corporativo de SQL "actividad actual" pantalla. Sin embargo, la manera más confiable para obtener esta información es inspeccionar el DBCC PSS de lo SPID de bloqueo en cuestión y observar el valor de pstat. Por ejemplo:

dbcc traceon(3604) /* Return subsequent DBCC output to the client rather                      than to the errorlog. */ 
go
SELECT SUID FROM SYSPROCESSES WHERE SPID=<unkillable SPID number>
go
DBCC PSS (suid, spid, 0) /* Where suid is from above, and spid is the
unkillable SPID number. */
go


La primera línea de la información devuelta contendrá el valor de pstat.


Por ejemplo, puede ser algo parecido a lo siguiente:

pstat=0x4000, 0x800, 0x100, 0x1

Significado de los bits de pstat:

0x4000 -- Delay KILL and ATTENTION signals if inside a critical section
0x2000 -- Process is being killed
0x800 -- Process is in backout, thus cannot be chosen as deadlock victim
0x400 -- Process has received an ATTENTION signal, and has responded by
raising an internal exception
0x100 -- Process in the middle of a single statement transaction
0x80 -- Process is involved in multi-database transaction
0x8 -- Process is currently executing a trigger
0x2 -- Process has received KILL command
0x1 -- Process has received an ATTENTION signal


El valor de pstat anterior sería una situación típica, si se ha cancelado una modificación de datos de larga duración (por ejemplo, pulsando el botón Cancelar consulta en una aplicación de interfaz gráfica de usuario) y, a continuación, se ha encontrado el SPID (durante un tiempo) para bloquear usuarios, todavía considerara. Esta situación es normal; la transacción debe deshacerse. Pueden identificarse por los bits, como se indicó anteriormente.

SPID 1 tiene un estado de 0000 (recuperación de ejecución)

Al iniciar (o reiniciar) de SQL Server, cada base de datos debe completar la recuperación de inicio antes de poder usarlo. Esto se considera el primer spid en sp_who tener estado 0000. No se eliminará, y recuperación debe poder ejecutarse hasta su finalización sin reiniciar el servidor. Sólo el usuario pueden ser sacrificados SPID, no sistema SPID como la escritura diferida, checkpoint, Administrador de lecturas anticipadas y así sucesivamente. También no puede eliminar su propio spid. Puede encontrar que es el spid realizando SELECT @@SPID.



Servidor ha demorado intencionalmente teniendo en cuenta la interrupción

En algunas situaciones, el servidor aplaza intencionadamente que actúe sobre un comando KILL o una señal de atención (una solicitud de cancelación de consulta). Un ejemplo de esto es en una sección crítica. Estos intervalos son generalmente breves. Esta situación puede verse como un valor de pstat de 0 x 4000.

Ruta de acceso del código no comprueba KILL

Si eliminar cada uno de los escenarios anteriores, es posible que la ruta de acceso de código actual simplemente no está comprobando KILL. Por ejemplo, antes de SQL Server versión 6.5 Service Pack 3, DBCC CHECKDB no confiable respondió a KILL porque determinadas rutas de código no protegerlo. Si se han excluido todas las situaciones anteriores (es decir, el proceso de usuario no está en espera de i/OS y no en rollback, la base de datos no está en recuperación y SQL Server no está aplazando intencionadamente KILL) aún no está siendo honrado KILL, es posible mejorar el servidor para que funcione dicho KILL. Para realizar esta determinación, se debe examinar individualmente cada caso por su proveedor de soporte técnico principal.


Otra información

El hecho de que el mensaje "Id. de proceso 10 sacrificados por nombre de host JOE" se escribe en el registro de errores no confirma que la eliminación ha tenido lugar. Este mensaje se escribe inmediatamente después de realizar la solicitud de interrupción, pero no significa que se ha liquidado la interrupción.


Propiedades

Id. de artículo: 171224 - Última revisión: 01/23/2017 - Revisión: 1

Microsoft SQL Server 6.0 Standard Edition, Microsoft SQL Server 6.5 Standard Edition

Comentarios