Seguimiento del Summer Performance Palooza 2013

El 27 de junio, PASS Performance Virtual Chapter celebró su Summer Performance Palooza 2013, una especie de 24 horas de PASS reducidas, pero centradas únicamente en temas relacionados con el rendimiento. Di una sesión titulada "10 malos hábitos que pueden matar el rendimiento", tratando los siguientes 10 conceptos:

1. SELECCIONAR *
2. Índices ciegos
3. Sin prefijo de esquema
4. Opciones de cursor predeterminadas
5. prefijo sp_
6. Permitir la sobrecarga de caché
7. Tipos de datos amplios
8. Valores predeterminados de SQL Server
9. Uso excesivo de funciones
10. "Funciona en mi máquina"

Es posible que recuerde algunos de estos temas de presentaciones tales como mi charla "Malos hábitos y mejores prácticas" o nuestros seminarios web semanales de ajuste de consultas que he estado organizando con Kevin Kline desde principios de junio hasta esta semana. (Por cierto, esos 6 videos estarán disponibles a principios de agosto en YouTube).

Mi sesión tuvo 351 asistentes y obtuve excelentes comentarios. Quería abordar algo de eso.

Primero, un problema de configuración:estaba usando un micrófono nuevo y no tenía idea de que cada pulsación de tecla sonaría como un trueno. Abordé ese problema con una mejor ubicación de mis periféricos, pero quiero disculparme con todos los afectados por eso.

A continuación, las descargas; la plataforma y las muestras se publican en el sitio del evento. Están en la parte inferior de la página, pero también puedes descargarlos aquí mismo.

Finalmente, lo que sigue es una lista de preguntas que se publicaron durante la sesión, y quería asegurarme de abordar las que no se respondieron durante la sesión de preguntas y respuestas en vivo. Me disculpo por haberlo incluido en poco menos de un mes. , pero había hubo muchas preguntas y no quería publicarlas por partes.

R: Deberá abordar esto caso por caso, ya que realmente dependerá de una variedad de factores (incluida la complejidad del plan). También tenga en cuenta que puede hacer una recompilación a nivel de declaración de modo que solo las declaraciones afectadas tengan que recibir el golpe, a diferencia de todo el módulo. Paul White me recordó que la gente suele 'arreglar' el rastreo de parámetros con RECOMPILE , pero con demasiada frecuencia eso significa WITH RECOMPILE al estilo 2000 en lugar de la mucho mejor OPTION (RECOMPILE) , que no solo se limita a la declaración, sino que también permite la incrustación de parámetros, lo que WITH RECOMPILE no es. Entonces, si vas a usar RECOMPILE para frustrar el rastreo de parámetros, agréguelo a la instrucción, no al módulo.

R: Como se indicó anteriormente, esto dependerá del costo y la complejidad de los planes y no hay forma de decir:"Sí, siempre habrá un gran impacto en el rendimiento". También debe asegurarse de comparar eso con la alternativa.

R: No estoy seguro de lo que significa "legible en el mundo real". Si quiere decir que desea la salida en un formato específico, generalmente es mejor convertirlo a una cadena en el lado del cliente. C# y la mayoría de los demás lenguajes que probablemente utilice en el nivel de presentación son más que capaces de formatear la salida de fecha/hora de la base de datos en cualquier formato regional que desee.

R: La mayoría de los DMV solo son válidos desde el último inicio del servicio, e incluso otros pueden descargarse con más frecuencia (incluso a pedido, tanto inadvertidamente como a propósito). El caché del plan, por supuesto, está en constante cambio, y AFAIK los planes que se caen del caché no mantienen su conteo anterior si vuelven a aparecer. Entonces, incluso cuando ves un plan en el caché, no estoy al 100%. confíe en que puede creer el recuento de uso que encuentre.

Dicho esto, lo que probablemente esté buscando es sys.dm_exec_cached_plans.usecounts y también puede encontrar sys.dm_exec_procedure_stats.execution_count para ayudar a complementar la información de los procedimientos donde las declaraciones individuales dentro de los procedimientos no se encuentran en el caché.

R: Las principales preocupaciones en torno a esto son la capacidad de usar cierta sintaxis, como OUTER APPLY o variables con una función con valores de tabla. No tengo conocimiento de ningún caso en el que el uso de una compatibilidad más baja tenga un impacto directo en el rendimiento, pero un par de cosas que normalmente se recomiendan son reconstruir índices y actualizar estadísticas (y hacer que su proveedor admita el nivel de compatibilidad más nuevo lo antes posible). Lo he visto resolver una degradación inesperada del rendimiento en una cantidad considerable de casos, pero también he escuchado algunas opiniones de que hacerlo no es necesario y tal vez incluso imprudente.

R: No, al menos en términos de rendimiento, una excepción donde SELECT * no importa es cuando se usa dentro de un EXISTS cláusula. Pero, ¿por qué usarías *? ¿aquí? Prefiero usar EXISTS (SELECT 1 ... – el optimizador los tratará de la misma manera, pero de alguna manera autodocumenta el código y asegura que los lectores entiendan que la subconsulta no devuelve ningún dato (incluso si se pierden el gran EXISTS fuera). Algunas personas usan NULL , y no tengo idea de por qué comencé a usar 1, pero encuentro NULL un poco poco intuitivo también.

*Nota* deberá tener cuidado si intenta usar EXISTS (SELECT *) dentro de un módulo que está vinculado a un esquema:

CREATE VIEW dbo.ThisWillNotWork
WITH SCHEMABINDING
AS
  SELECT BusinessEntityID
    FROM Person.Person AS p
	WHERE EXISTS (SELECT * FROM Sales.SalesOrderHeader AS h
	  WHERE h.SalesPersonID = p.BusinessEntityID);

Obtienes este error:

Sin embargo, cambiarlo a SELECT 1 funciona bien Así que tal vez ese sea otro argumento para evitar SELECT * incluso en ese escenario.

R: Probablemente hay cientos en una variedad de idiomas. Al igual que las convenciones de nombres, los estándares de codificación son algo muy subjetivo. Realmente no importa qué convención decidas que funciona mejor para ti; si te gusta tbl prefijos, ¡vuélvete loco! Prefiere Pascal sobre bigEndian, hazlo. Desea anteponer los nombres de sus columnas con el tipo de datos, como intCustomerID , no te voy a detener. Lo más importante es que defina una convención y la emplee *consistentemente.*

Dicho esto, si quieres mis opiniones, no me faltan.

R: No sé de ningún plan para desaprobar XACT_ABORT por lo que debería seguir funcionando bien. Francamente, no veo que esto se use muy a menudo ahora que tenemos TRY / CATCH (y THROW a partir de SQL Server 2012).

R: No probé esto, pero en muchos casos, reemplazar una función escalar con una función con valores de tabla en línea puede tener un gran impacto en el rendimiento. El problema que encuentro es que hacer este cambio puede ser una cantidad sustancial de trabajo en el sistema que se escribió antes de APPLY existieron, o aún son administrados por personas que no han adoptado este mejor enfoque.

R: Dos cosas saltan a la mente:(1) la demora tiene que ver con el tiempo de compilación o (2) la demora tiene que ver con la cantidad de datos que se cargan para satisfacer la consulta, y la primera vez tiene que provenir del disco y no la memoria. Para (1) puede ejecutar la consulta en SQL Sentry Plan Explorer y la barra de estado le mostrará el tiempo de compilación para la primera invocación y las subsiguientes (aunque un minuto parece bastante excesivo para esto, y poco probable). Si no encuentra ninguna diferencia, puede deberse simplemente a la naturaleza del sistema:memoria insuficiente para admitir la cantidad de datos que intenta cargar con esta consulta en combinación con otros datos que ya estaban en el grupo de búfer. Si no cree que ninguno de estos sea el problema, vea si las dos ejecuciones diferentes realmente producen planes diferentes; si hay alguna diferencia, publique los planes en answers.sqlperformance.com y estaremos encantados de echar un vistazo. . De hecho, la captura de planes reales para ambas ejecuciones utilizando el Explorador de planes en cualquier caso también puede informarle sobre las diferencias en la E/S y puede conducir a dónde SQL Server está gastando su tiempo en la primera ejecución más lenta.

R: No, no creo que la configuración Optimizar para cargas de trabajo ad hoc ayude en este escenario, ya que la detección de parámetros implica que las ejecuciones posteriores del mismo plan se usan para diferentes parámetros y con comportamientos de rendimiento significativamente diferentes. Optimize for ad hoc workloads se usa para minimizar el impacto drástico en la memoria caché del plan que puede ocurrir cuando tiene una gran cantidad de instrucciones SQL diferentes. Entonces, a menos que esté hablando del impacto en el caché del plan de muchas declaraciones diferentes que está enviando a sp_executesql – que no se caracterizaría como rastreo de parámetros – creo que experimentando con OPTION (RECOMPILE) puede tener un mejor resultado o, si conoce los valores de los parámetros que *sí* producen buenos resultados en una variedad de combinaciones de parámetros, use OPTIMIZE FOR . Esta respuesta de Paul White puede proporcionar una perspectiva mucho mejor.

R: Claro, solo incluye OPTION (RECOMPILE) en el texto SQL dinámico:

DBCC FREEPROCCACHE;
 
USE AdventureWorks2012;
GO
SET NOCOUNT ON;
GO
 
EXEC sp_executesql 
  N'SELECT TOP (1) * INTO #x FROM Sales.SalesOrderHeader;';
GO
EXEC sp_executesql 
  N'SELECT TOP (1) * INTO #x FROM Sales.SalesOrderDetail OPTION (RECOMPILE);'
GO
 
SELECT t.[text], p.usecounts
FROM sys.dm_exec_cached_plans AS p
CROSS APPLY sys.dm_exec_sql_text(p.[plan_handle]) AS t
WHERE t.[text] LIKE N'%Sales.' + 'SalesOrder%';

Resultados:1 fila que muestra Sales.SalesOrderHeader consulta.

Ahora, si alguna declaración en el lote NO incluye OPTION (RECOMPILE) , es posible que el plan aún se almacene en caché, simplemente no se puede reutilizar.

DBCC FREEPROCCACHE(0x06.....);