La supervisión del rendimiento y la resolución de problemas en SQL Server es un tema muy amplio. En SQL Server 2005, se introdujeron vistas de administración dinámica, también conocidas como DMV, y se convirtieron en una herramienta de ayuda esencial para diagnosticar problemas de rendimiento de SQL Server. Al mismo tiempo, podemos usar vistas de administración dinámicas para Azure SQL Database. Algunos de ellos pueden diferir de la base de datos local de SQL Server, pero la lógica de trabajo sigue siendo la misma. Microsoft tiene muy buena documentación sobre vistas de gestión dinámica. Lo único que debe tener cuidado con la versión y la validación del producto de las vistas de administración dinámica. Por ejemplo, sys.dm_exec_request está disponible para SQL Server 2008 y versiones posteriores y para la base de datos de Azure SQL, pero sys.dm_db_wait_stats solo es válido para la base de datos de Azure SQL.
En esta publicación, hablaremos sobre los conceptos básicos de sys.dm_exec_request. sys.dm_exec_requests es una vista de administración dinámica que devuelve solo las solicitudes que se están ejecutando actualmente. Significa que cuando ejecuta la consulta sys.dm_exec_requests, toma una instantánea de la solicitud que se está ejecutando en ese momento y no incluye ningún dato histórico. Por lo tanto, esta vista es muy útil para monitorear solicitudes en tiempo real. En otras palabras, da la respuesta a "¿qué está pasando en mi servidor en este momento?" Esta vista incluye muchos detalles, pero discutiremos los más importantes.
id_de_sesión :este valor define un número de identificación de sesión. En SQL Server, los ID de sesión que son iguales o inferiores a 50 se dedican al proceso en segundo plano.
hora_de_inicio :Este valor define la fecha y hora de inicio de la solicitud.
estado :este valor define un estado de la solicitud. Los estados disponibles son:
- fondo
- corriendo
- ejecutable
- dormir
- suspendido
SELECT DISTINCT status FROM sys.dm_exec_requests WHERE session_id <>@@SPID
fondo :este tipo de estado define los procesos en segundo plano. Algunos de ellos son LAZY WRITER, CHECKPOINT y LOG WRITER.
select session_id, command, os_thread_id from sys.dm_exec_requests as r join sys.dm_os_workers as w on r.task_address = w.task_address join sys.dm_os_threads as t on t.thread_address = w.thread_address where session_id <= 50 order by session_id
corriendo :este tipo de estado define que la CPU está procesando la solicitud.
select * from sys.dm_exec_requests where status='running' and session_id <>@@SPID
ejecutable :este tipo de estado se puede definir simplemente como una solicitud que está esperando en la cola de la CPU para ejecutarse. Si detecta muchos procesos ejecutables en sys.dm_exec_requests, puede ser un síntoma de la presión de la CPU. Esta métrica no es suficiente para diagnosticar este problema de rendimiento de la CPU. Por esta razón, necesitamos apoyar este caso con más evidencia. Esto es importante para nosotros para probar nuestra teoría. La vista de administración dinámica sys.dm_os_wait_stats incluye una columna que es signal_wait_time_ms. Este valor de columna puede ser una ayuda para determinar el problema de la CPU. La siguiente consulta nos muestra el porcentaje de Signalwait. Si esta métrica tiene un valor alto, lo más probable es que esté enfrentando un problema de rendimiento de la CPU. Puede profundizar su revisión de esta manera.
---https://sqlserverperformance.wordpress.com/page/146/ ---Glenn Berry's SQL Server Performance SELECT signal_wait_time_ms=SUM(signal_wait_time_ms) ,'%signal (cpu) waits' = CAST(100.0 * SUM(signal_wait_time_ms) / SUM (wait_time_ms) AS NUMERIC(20,2)) ,resource_wait_time_ms=SUM(wait_time_ms - signal_wait_time_ms) ,'%resource waits'= CAST(100.0 * SUM(wait_time_ms - signal_wait_time_ms) / SUM (wait_time_ms) AS NUMERIC(20,2)) FROM sys.dm_os_wait_stats;
suspendido :Este tipo de estado define el proceso de espera de algún recurso. Puede ser E/S, LOCK y LATCH, etc. Como se mencionó anteriormente, podemos usar sys.dm_os_wait_stats vista de administración dinámica para detectar wait_time_ms.
durmiendo :Significa que la solicitud está conectada a SQL Server pero actualmente no está ejecutando ningún comando.
comando :Esta columna define un tipo de comando que se está ejecutando. Al mismo tiempo, podemos encontrar información adicional para comandos particulares, que es una tasa de finalización. Según los libros en línea, estos son:
ALTER ÍNDICE REORGANIZAR
Opción AUTO_SHRINK con ALTER DATABASE
RESPALDO DE BASE DE DATOS
DBCC CHECKDB
DBCC CHECKFILEGROUP
TABLA DE COMPROBACIÓN DBCC
DBCC INDEXDEFRAG
DBCC SHRINKDATABASE
ARCHIVO REDUCTOR DBCC
RECUPERACIÓN
RESTAURAR BASE DE DATOS
RETROCEDER
CIFRADO TDE
Demostración :
- Conecte la base de datos maestra e inicie la copia de seguridad de cualquier base de datos.
BACKUP DATABASE WideWorldImporters TO DISK ='NUL'
Consejo :Cuando lleva la copia de seguridad de la base de datos al dispositivo "NUL", SQL Server no escribe un archivo de copia de seguridad en ninguna parte y evita la eliminación de un archivo de copia de seguridad de prueba. Pero no use este comando en su entorno de producción. Puede causar que se rompa la cadena LSN.
Ejecute la siguiente consulta:
SELECT command,percent_complete ,* FROM sys.dm_exec_requests WHERE session_id <>@@SPID and session_id>50 and command='BACKUP DATABASE'
sql_handle :este valor define la instrucción SQL de la solicitud. Pero este valor está en formato de mapa de bits. Por esta razón, necesitamos usar la función con valores de tabla sys.dm_exec_sql_text para convertir el valor en texto significativo.
select session_id ,command , sqltxt.text ,database_id from sys.dm_exec_requests req CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt where session_id<>@@SPID AND session_id>50
id_de_base_de_datos :este valor define qué base de datos realiza la solicitud. Podemos unir este campo con sys.databases para obtener el nombre de la base de datos.
select session_id ,command , sqltxt.text ,db.name from sys.dm_exec_requests req CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt inner join sys.databases db on db.database_id = req.database_id where session_id<>@@SPID AND session_id>50
tipo_espera :este valor define el tipo de espera actual de la solicitud. Si la duración de la ejecución de la consulta tarda más de lo esperado, puede verificar y determinar el tipo de espera de la consulta.
nivel_de_aislamiento_de_transacción :este valor define el nivel de transacción de la consulta enviada:
0=Sin especificar
1=Lectura no confirmada
2=Lectura confirmada
3=Repetible
4=Serializable
5=Instantánea
select session_id ,command , sqltxt.text ,db.name,req.status,wait_type ,transaction_isolation_level, CASE transaction_isolation_level WHEN 0 THEN 'Unspecified' WHEN 1 THEN 'ReadUncomitted' WHEN 2 THEN 'ReadCommitted' WHEN 3 THEN 'Repeatable' WHEN 4 THEN 'Serializable' WHEN 5 THEN 'Snapshot' END AS isolation_level_name from sys.dm_exec_requests req CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt inner join sys.databases db on db.database_id = req.database_id where session_id<>@@SPID AND session_id>50
blocking_session_id :Es el id de la sesión que está bloqueando la solicitud. Si esta columna es NULL, la solicitud no ha bloqueado ninguna sesión.
Demostración :
- Abra SQL Server Management Studio y ejecute la siguiente consulta.
DROP TABLE IF EXISTS TestPerfomon GO CREATE TABLE TestPerfomon (ID INT , Nm VARCHAR(100)) INSERT INTO TestPerfomon VALUES(1,1) GO BEGIN TRAN UPDATE TestPerfomon SET Nm='2' WHERE ID=1 SELECT @@SPID AS blocking_session_id
Abra una nueva ventana de consulta y ejecute la siguiente consulta.
SET TRANSACTION ISOLATION LEVEL Serializable BEGIN TRAN UPDATE TestPerfomon SET Nm='3' WHERE ID=1
Abra otra nueva ventana de consulta y ejecute esta consulta del DMV.
select session_id ,command , sqltxt.text ,db.name,req.status,wait_type ,transaction_isolation_level, CASE transaction_isolation_level WHEN 0 THEN 'Unspecified' WHEN 1 THEN 'ReadUncomitted' WHEN 2 THEN 'ReadCommitted' WHEN 3 THEN 'Repeatable' WHEN 4 THEN 'Serializable' WHEN 5 THEN 'Snapshot' END AS isolation_level_name , blocking_session_id from sys.dm_exec_requests req CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt inner join sys.databases db on db.database_id = req.database_id where session_id<>@@SPID AND session_id>50
Con esta demostración, descubrimos la razón por la que se bloquea la segunda consulta y en qué sesión se bloquea la solicitud. Cuando ejecuta sp_BlitzWho 65, puede averiguar los detalles del bloqueo y los detalles de la sesión bloqueada.
sp_BlitzWho 65
En esta demostración, recuperamos los detalles del bloqueo y las sesiones bloqueadas y, al mismo tiempo, obtuvimos los detalles sobre estas sesiones. Esta es una demostración muy básica, pero muestra cómo se puede resolver el problema.
En esta publicación, hablamos sobre sys.sys.dm_exec_requests. Esta vista de administración dinámica nos brinda la flexibilidad de obtener una instantánea durante el renglón actual de una solicitud. Además, estos datos detallados pueden ayudarnos o guiarnos a través del proceso de detección del problema.
Referencias
- sys.dm_exec_requests (Transact-SQL)
- Supervisión de Azure SQL Database mediante vistas de administración dinámica
- sys.dm_db_wait_stats (base de datos Azure SQL)
Herramienta útil:
dbForge Monitor:complemento para Microsoft SQL Server Management Studio que le permite realizar un seguimiento y analizar el rendimiento de SQL Server.