Como usted sabe, la responsabilidad principal del administrador de la base de datos radica en monitorear el desempeño de SQL Server e intervenir en un tiempo determinado. Puede encontrar varias herramientas de monitoreo del rendimiento de SQL Server en el mercado, pero a veces necesitamos información adicional sobre el rendimiento de SQL Server para diagnosticar y solucionar los problemas de rendimiento. Por lo tanto, debemos tener suficiente información sobre las vistas de administración dinámica de SQL Server para manejar los problemas relacionados con SQL Server.
Dynamic Management View (DMV) es un concepto que nos ayuda a descubrir las métricas de rendimiento de SQL Server Engine. El DMV se anunció por primera vez en la versión de SQL Server 2005 y continuó en todas las versiones de SQL Server posteriormente. En esta publicación, hablaremos sobre el DMV en particular, cuyo administrador de base de datos debe tener suficiente información. Este es sys.dm_os_wait_stats .
sys.dm_os_wait_stats
sys.dm_os_wait_stats admite métricas esenciales para diagnosticar problemas de rendimiento de SQL Server. Si tiene algunos problemas (CPU, memoria, E/S, bloqueo, pestillo, etc.) en SQL Server Engine, los datos de sys.dm_os_wait_stats nos guían para definir el problema. El Monitor de actividad en SQL Server Management Studio incluye un panel llamado "Esperas de recursos ”. "Resource Waits" obtiene estas métricas de un procedimiento almacenado especial. Este nombre de procedimiento almacenado temporal es "#am_generate_waitstats ” y usa sys.dm_os_wait_stats. Puede encontrar este procedimiento almacenado temporal en "tempdb". En este punto, me gustaría agregar algunas notas sobre el procedimiento almacenado temporal. Porque este tipo de procedimiento almacenado no tiene un uso común.
El procedimiento almacenado temporal no difiere de los procedimientos almacenados permanentes. Tiene dos tipos:locales y globales como tablas temporales. El procedimiento almacenado local permanece activo en la sesión actual y se descarta después de que se cierra la sesión. Se puede crear así:
CREATE PROCEDURE #LocalTestSP AS PRINT Hello Local Stored Procedure
El procedimiento almacenado global también permanece activo en todas las sesiones y se elimina después de que se cierra la sesión creada. El procedimiento almacenado global se puede crear como:
CREATE PROCEDURE ##GlobalTestSP AS PRINT Hello Global Stored Procedure
Consejo: Cuando abrimos el Monitor de actividad, crea el #am_generate_waitstats procedimiento almacenado temporal y lo descarta después del cierre.
Ahora veremos la idea principal y los detalles de sys.dm_os_wait_stats . La siguiente consulta devolverá todos los datos sobre las "Estadísticas de espera" de SQL Server. Esta consulta está en su forma más pura. Es un inconveniente detectar problemas con dicho formulario. En las siguientes secciones, encontrará consultas más útiles que sys.dm_os_wait_stats. Ahora explicaremos la descripción de las columnas de "Estadísticas de espera" de SQL Server:
SELECT * FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC
La columna wait_type contiene la definición o el nombre de las estadísticas de espera. Los datos de la columna wait_type son significativos para nosotros porque la definición de las estadísticas de espera indica el motivo principal del problema. wait_tasks_count indica la frecuencia del tipo de espera que se produjo en SQL Server.
tiempo_de_espera_ms indica el tiempo total de espera. La unidad de medida es un milisegundo.
max_wait_time_ms indica el tiempo máximo de espera.
señal_espera_tiempo_ms se describe en MSDN como "Diferencia entre el momento en que se señaló el subproceso en espera y cuando comenzó a ejecutarse". El valor especialmente alto de esta columna indica la presión de la CPU. Entonces, la consulta está esperando en la cola ejecutable y lista para ejecutarse, pero la CPU está ocupada con otras consultas. Por este motivo, la consulta está esperando en la cola. Cuando el recurso de la CPU esté disponible, la CPU obtendrá una nueva consulta de la cola ejecutable y comenzará a procesar. En resumen, podemos describir signal_wait_time_ms como tiempo de espera en la cola ejecutable que está en estado de ejecución ejecutable.
Consejo: En la mejor práctica, las diversas estadísticas de espera son más importantes que las demás. Estos se pueden enumerar como:
• PAGEIOLATCH_*
• REGISTRO DE ESCRITURA
• ASYNC_NETWORK_IO
• CXPACKET
• CPU
• LCK_M_*
• PREVENTIVO_*
• PAGELATCH_*
Eche un vistazo a las consultas de estadísticas de espera de Pinal Dave o Paul S. Randal. Eliminaron varios tipos de estadísticas de espera en sus consultas. Los siguientes tipos de espera de recursos se pueden eliminar en sys.dm_os_wait_stats consultas:
• BROKER_EVENTHANDLER
• BROKER_RECEIVE_WAITFOR
• BROKER_TASK_STOP
• BROKER_TO_FLUSH
• BROKER_TRANSMITTER
• CHECKPOINT_QUEUE
• CHKPT
• CLR_AUTO_EVENT
• CLR_MANUAL_EVENT
• CLR_SEMAPHORE
• DBMIRROR_DBM_EVENT
• DBMIRROR_DBM_MUTEX
• DBMIRROR_EVENTS_QUEUE
• DBMIRROR_WORKER_QUEUE
• DBMIRRORING_CMD
• DIRTY_PAGE_POLL
• DISPATCHER_QUEUE_SEMAPHORE
• EXECSYNC
• FSAGENT
• FT_IFTS_SCHEDULER_IDLE_WAIT
• FT_IFTSHC_MUTEX
• HADR_CLUSAPI_CALL
• HADR_FILESTREAM_IOMGR_IOCOMPLETION
• HADR_LOGCAPTURE_WAIT
• HADR_NOTIFICATION_DEQUEUE
• HADR_TIMER_TASK
• HADR_WORK_QUEUE
• LAZYWRITER_SLEEP
• LOGMGR_QUEUE
• MEMORY_ALLOCATION_EXT
• ONDEMAND_TASK_QUEUE
• PREEMPTIVE_HADR_LEASE_MECHANISM
• PREEMPTIVE_OS_AUTHENTICATIONOPS
• PREEMPTIVE_OS_AUTHORIZATION
• PREEMPTIVE_OS_COMOPS
• PREEMPTIVE_OS_CREATEFILE
• PREEMPTIVE_OS_CRYPTOPS
• PREEM PTIVE_OS_DEVICEOPS
• PREEMPTIVE_OS_FILEOPS
• PREEMPTIVE_OS_GENERICOPS
• PREEMPTIVE_OS_LIBRARYOPS
• PREEMPTIVE_OS_PIPEOPS
• PREEMPTIVE_OS_QUERYREGISTRY
• PREEMPTIVE_OS_VERIFYTRUST
• PREEMPTIVE_OS_WAITFORSINGLEOBJECT<•• PREEMPTIVE_OS_WAITFORSINGLEOBJECT<•• br />• PREEMPTIVE_SP_SERVER_DIAGNOSTICS
• PREEMPTIVE_XE_GETTARGETSTATE
• PWAIT_ALL_COMPONENTS_INITIALIZED
• PWAIT_DIRECTLOGCONSUMER_GETNEXT
• QDS_ASYNC_QUEUE
• QDS_CLEANUP_STALE_QUERIES_TASK_MAIN_LOOP_SLEEP
• QDS_PERSIST_TASK_MAIN_LOOP_SLEEP
• QDS_SHUTDOWN_QUEUE
• REDO_THREAD_PENDING_WORK
• REQUEST_FOR_DEADLOCK_SEARCH
• RESOURCE_QUEUE
• SERVER_IDLE_CHECK
• SLEEP_BPOOL_FLUSH
• SLEEP_DBSTARTUP
• SLEEP_DCOM STARTUP
• SLEEP_MASTERDBREADY
• SLEEP_MASTERMDREADY
• SLEEP_MASTERUPGRADED
• SLEEP_MSDBSTARTUP
• SLEEP_SYSTEMTASK
• SLEEP_TASK
• SP_SERVER_DIAGNOSTICS_SLEEP
• SQLTRACE_BUFFER_FLUSH
• SQLTRACE _INCREMENTAL_FLUSH_SLEEP
• SQLTRACE_WAIT_ENTRIES
• UCS_SESSION_REGISTRATIO
• WAIT_FOR_RESULTS
• WAIT_XTP_CKPT_CLOSE
• WAIT_XTP_HOST_WAIT
• WAIT_XTP_OFFLINE_CKPT_NEW_LOG
• WAIT_XTP_FOR
• WAIT_XTP_FOR
• WAIT_XTP_FOR
br />• WAITFOR_TASKSHUTDOW
• XE_TIMER_EVENT
• XE_DISPATCHER_WAIT
• XE_LIVE_TARGET_TVF
Consejo: SQL Server comienza a recopilar datos DMV cuando se inicia o se reinicia. SQL Server restablece automáticamente las estadísticas de espera cuando se reinicia y la siguiente consulta obliga a restablecer las estadísticas de espera desde que SQL Server se reinició por última vez:
DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR) Además, la precisión de la medición de las estadísticas de espera es el punto clave. En este punto podemos considerar dos enfoques:
• Restablezca las estadísticas de espera y recopile las estadísticas de espera.
• Capture dos "estadísticas de tiempo de espera" diferentes y mida la diferencia en los valores.
En mi opinión, capturar y almacenar estadísticas de espera para cualquier enfoque de tabla de historial es mejor que otro. En este método, puede medir un intervalo de tiempo particular y no perder las estadísticas de espera de los datos históricos.
Ahora haremos una muestra de la captura de estadísticas de espera y mostraremos los datos capturados en Power BI con gráficos.
Crearemos una tabla de historial para almacenar estadísticas de espera:
CREATE TABLE [dbo].[HistoryOfWaitStatistics]( [SQLStartTime] [datetime] NULL, [Dt] [datetime] NOT NULL, [WaitType] [nvarchar](60) NOT NULL, [WaitTimeSecond] [numeric](25, 6) NULL, [ResourcesWaitSecond] [numeric](25, 6) NULL, [SignalWaitSecond] [numeric](25, 6) NULL ) ON [PRIMARY]
El siguiente script inserta "estadísticas de espera" en la tabla de historial. Pero debe programar esta consulta en Agente SQL Server para almacenar la tabla de historial:
DROP TABLE IF exists #eliminate_WS
CREATE TABLE #eliminate_WS (wait_type NVARCHAR(100));
INSERT INTO #eliminate_WS VALUES ('ASYNC_IO_COMPLETION');
INSERT INTO #eliminate_WS VALUES ('CHECKPOINT_QUEUE');
INSERT INTO #eliminate_WS VALUES ('CHKPT');
INSERT INTO #eliminate_WS VALUES ('CXPACKET');
INSERT INTO #eliminate_WS VALUES ('DISKIO_SUSPEND');
INSERT INTO #eliminate_WS VALUES ('FT_IFTS_SCHEDULER_IDLE_WAIT');
INSERT INTO #eliminate_WS VALUES ('IO_COMPLETION');
INSERT INTO #eliminate_WS VALUES ('KSOURCE_WAKEUP');
INSERT INTO #eliminate_WS VALUES ('LAZYWRITER_SLEEP');
INSERT INTO #eliminate_WS VALUES ('LOGBUFFER');
INSERT INTO #eliminate_WS VALUES ('LOGMGR_QUEUE');
INSERT INTO #eliminate_WS VALUES ('MISCELLANEOUS');
INSERT INTO #eliminate_WS VALUES ('PREEMPTIVE_XXX');
INSERT INTO #eliminate_WS VALUES ('REQUEST_FOR_DEADLOCK_SEARCH');
INSERT INTO #eliminate_WS VALUES ('RESOURCE_QUERY_SEMAPHORE_COMPILE');
INSERT INTO #eliminate_WS VALUES ('RESOURCE_SEMAPHORE');
INSERT INTO #eliminate_WS VALUES ('SOS_SCHEDULER_YIELD');
INSERT INTO #eliminate_WS VALUES ('SQLTRACE_BUFFER_FLUSH ');
INSERT INTO #eliminate_WS VALUES ('THREADPOOL');
INSERT INTO #eliminate_WS VALUES ('WRITELOG');
INSERT INTO #eliminate_WS VALUES ('XE_DISPATCHER_WAIT');
INSERT INTO #eliminate_WS VALUES ('XE_TIMER_EVENT');
INSERT INTO HistoryOfWaitStatistics
SELECT
(SELECT sqlserver_start_time FROM sys.dm_os_sys_info ) as SQLStartTime,GETDATE() AS Dt,Wait_type as WaitType,
wait_time_ms / 1000. AS WaitTimeSecond,
(wait_time_ms - signal_wait_time_ms)/1000. AS ResourcesWaitSecond,
signal_wait_time_ms/1000. AS SignalWaitSecond
FROM sys.dm_os_wait_stats
WHERE wait_type IN(SELECT wait_type FROM #eliminate_WS) Una vez que se han almacenado los datos históricos, abrimos Power BI y desarrollamos nuestro panel de estadísticas de espera.
Haz clic en Obtener datos y seleccione Servidor SQL :
Establezca la configuración de conexión y luego escriba la consulta en instrucción SQL (opcional, requiere una base de datos) . Haz clic en Aceptar .
Haz clic en Importar desde Marketplace
Encuentra Sparkline de OKViz componente visual y Añadir BI de energía
Agregue Sparkline al panel de diseño de Power BI y arrastre y suelte las columnas del conjunto de datos como se muestra en la siguiente imagen:
Agregue dos componentes de tabla para filtrar:SQLStartTime y Tipo de espera . Finalmente, el tablero debería ser así:
Cómo diagnosticar un problema de espera de recursos:
En esta sección, mencionaremos la metodología y disciplina del diagnóstico de problemas de estadísticas de espera. En particular, tenemos que averiguar un punto sobre las estadísticas de espera:simplemente define la estructura principal del problema pero nunca da detalles. Por esta razón, necesitamos investigar los detalles y las razones de la espera. Por lo tanto, las "estadísticas de espera" nos permiten orientar nuestra investigación en esta dirección. Después, debemos usar otras herramientas (PerfMon, Extended Events, herramientas de monitoreo de terceros, etc.) y otros DMV para definir problemas exactos.
Suponiendo que observamos ASYNC_NETWORK_IO en SQL Server, esta espera de recursos está relacionada con una conexión de red lenta de un lado del cliente al servidor. Pero esta información no ayuda a solucionar la razón principal del problema porque es posible que tengamos varias configuraciones de red entre el servidor y el cliente. Para este ejemplo necesitamos buscar:
• Consultas de grandes conjuntos de resultados
• Configuraciones de la tarjeta de interfaz de red
• Configuración del entorno de red entre los lados del servidor y el lado del cliente.
• Comprobar el ancho de banda del adaptador de red.
Como puede ver en el ejemplo, necesitamos completar algunas tareas para definir el problema exacto. Las estadísticas de espera no indican el objetivo del problema.
Conclusiones
En esta publicación, hablamos sobre el concepto principal de la vista de administración dinámica sys.dm_os_wait_stats. Al mismo tiempo, discutimos la simplicidad de uso y los puntos importantes en los que es necesario prestar atención.
Herramienta útil:
dbForge Monitor:complemento para Microsoft SQL Server Management Studio que le permite realizar un seguimiento y analizar el rendimiento de SQL Server.
