Microsoft no tiene la costumbre de desaprobar las cosas en estos días, pero cuando lo hacen, es por una razón, y ciertamente no es porque quieran hacerle la vida más difícil. Por el contrario, casi siempre es porque han desarrollado mejores y más modernas formas de resolver esos mismos problemas.
Pero los hábitos son difíciles de romper; pregúntame cómo lo sé. Con demasiada frecuencia, veo personas que se aferran a una forma más antigua de realizar alguna tarea, aunque existe una forma mejor.
Me gustaría compartir un par de ejemplos recientes que ayudan a ilustrar cómo el uso de características obsoletas de SQL Server continúa mordiéndonos. En esta primera parte, quiero hablar de…
procesos del sistema
La tabla del sistema sys.sysprocesses fue reemplazado en SQL Server 2005 por un conjunto de vistas de administración dinámica (DMV), en particular sys.dm_exec_requests , sys.dm_exec_sessions y sys.dm_exec_connections . La documentación oficial de sys.sysprocesses advierte:
Un ejemplo reciente
Recientemente, uno de nuestros equipos estaba investigando un problema de latencia del lector de registros. Prestamos mucha atención a la latencia aquí, junto con cualquier transacción de ejecución prolongada, debido al impacto posterior en las tecnologías que usan el lector de registros, como los grupos de disponibilidad y la replicación transaccional. Nuestras primeras advertencias generalmente se detectan en un panel que traza la latencia del lector de registros frente a la duración de la transacción (explicaré los puntos en el tiempo que etiqueté como t0 y t1 en breve):
Determinaron, digamos en el tiempo t0 , que cierta sesión tenía una transacción abierta que bloqueaba el proceso del lector de registros. Primero verificaron la salida de DBCC INPUTBUFFER , para tratar de determinar qué duró esta sesión, pero los resultados simplemente indicaron que también emitieron otros lotes durante su transacción:
event_type parameters event_info -------------- ---------- --------------- Language Event 0 SET ROWCOUNT 0;
Tenga en cuenta que DBCC INPUTBUFFER también tiene un reemplazo más capaz en las versiones modernas:sys.dm_exec_input_buffer . Y aunque no tiene una advertencia de obsolescencia explícita, la documentación oficial de DBCC comando tiene este suave empujón:
Después de no obtener nada del búfer de entrada, consultaron sys.sysprocesses :
SELECT spid, [status], open_tran, waittime, [cpu], physical_io, memusage, last_batch FROM sys.sysprocesses WHERE spid = 107;
Los resultados fueron igualmente inútiles, al menos en términos de determinar qué había estado haciendo la sesión para mantener su transacción abierta e interrumpir el lector de registro:
Estoy resaltando el physical_io columna porque este valor provocó una discusión sobre si querían o no arriesgarse a matar la sesión de sueño. La idea era que, en el caso de que todas esas E/S físicas fueran escrituras, eliminar la transacción podría resultar en una reversión prolongada y disruptiva, lo que podría empeorar aún más el problema. No voy a poner tiempos reales en esto, pero digamos que esto se convirtió en una conversación prolongada, y dejó el sistema en este estado desde el tiempo t0 al tiempo t1 en el gráfico anterior.
Por qué esto es un problema
El tema en este caso específico es que pasaron ese tiempo contemplando una decisión basada en información incompleta. ¿Esas E/S son lecturas o escrituras? Si el usuario tiene una transacción abierta y simplemente ha leído una gran cantidad de datos, el impacto de revertir esa transacción es mucho menor que si hubiera cambiado. muchos datos Entonces, en lugar de sys.sysprocesses , veamos qué es el DMV más moderno, sys.dm_exec_sessions , puede mostrarnos sobre esta sesión:
SELECT session_id, [status], open_transaction_count, cpu_time, [reads], writes, logical_reads, last_request_start_time, last_request_end_time FROM sys.dm_exec_sessions WHERE session_id = 107;
Resultados:
Aquí vemos que sys.dm_exec_sessions divide la E/S física por separado en lecturas y escrituras. Esto nos permite tomar una decisión mucho más informada, mucho más rápido que t1 - t0 , sobre el impacto potencial de una reversión. Si todas las E/S son escrituras, y dependiendo de cuán alto sea el número, es posible que dudemos un poco más y tal vez dediquemos el tiempo a tratar de localizar al usuario (para que podamos golpearle los nudillos o preguntarle por qué tiene una transacción abierta). ). Si sabemos que en su mayoría son lecturas, podemos optar por eliminar la sesión y forzar la reversión de la transacción.
Claro, sys.sysprocesses tiene dbid y waittime . Pero dbid es poco confiable y marginalmente útil de todos modos, particularmente para consultas entre bases de datos; hay mucha mejor información en sys.dm_tran_locks . La información de espera (tiempo y último tipo de espera) se puede encontrar en sys.dm_exec_requests , pero se ofrece información mucho más detallada en sys.dm_exec_session_wait_stats (agregado en SQL Server 2016). Una excusa que solía escuchar mucho era que sys.dm_exec_sessions faltaba open_tran , pero open_transaction_count se agregó en SQL Server 2012. Por lo tanto, hay muy pocas razones para pensar en usar sys.sysprocesses hoy.
Si desea descubrir con qué frecuencia sys.sysprocesses se ha hecho referencia desde que SQL Server se reinició por última vez, puede ejecutar esta consulta en los contadores de rendimiento DMV:
SELECT instance_name, cntr_value
FROM sys.dm_os_performance_counters
WHERE [object_name] LIKE N'%:Deprecated Features%'
AND instance_name = N'sysprocesses'
ORDER BY cntr_value DESC;
Si realmente quiere evitar dormir esta noche, o simplemente le gusta agregar constantemente a la lista de cosas que le preocupan, elimine el predicado contra instance_name . Esto le dará una idea aterradora y de alto nivel de cuántas cosas están ejecutando sus instancias que eventualmente necesitará cambiar.
Mientras tanto, descarga sp_WhoIsActive , el ultra útil procedimiento almacenado de Adam Machanic para monitorear y solucionar problemas de procesos de SQL Server en tiempo real. Hemos implementado este procedimiento almacenado en cada instancia de nuestro entorno, y usted también debería hacerlo, independientemente de las otras herramientas de supervisión de alto nivel que pueda estar utilizando.
La próxima vez
En la Parte 2, hablaré un poco sobre SQL Server Profiler, una aplicación que la gente usa más por familiaridad que por cualquier otra cosa, sin darse cuenta de lo peligrosa que puede ser.
