¿Cuáles son los 3 principales problemas de rendimiento que encuentra con sus servidores SQL?

Soy un estudiante de la Universidad Fontys en Eindhoven, y actualmente estoy realizando una serie de entrevistas para ayudar con el desarrollo de una herramienta de SQL Server y me gustaría recibir comentarios de los expertos en el campo.

Una de mis preguntas es:

¿Cuáles son los 3 principales problemas de rendimiento que encuentra con sus instancias de SQL Server y cómo identifica esos problemas?

Particularmente estoy interesado en los scripts y las herramientas utilizadas para medir esto.

Fuera de la cabeza - 3 problemas de consulta principales:

• Conversiones implícitas
• Malas estrategias de indexación (demasiadas o no suficientes o del tipo incorrecto)
• Usando SELECT * en lugar de nombrar solo los campos que necesita

Hay mucho más sobre problemas de configuración a nivel de servidor, problemas de esquema de base de datos, problemas de hardware, etc. Escribí un script para analizar rápidamente los servidores en busca de este tipo de problemas:

http://www.brentozar.com/blitz/

• Diseño deficiente / consultas / indexación
• No está permitido comprar el hardware correcto
• Braindead ORMs (también conocido como "SQL está muerto")

No es el top 3, pero pensé que mencionaría cosas que aún no se han mencionado:

1. SQL puso en máquinas virtuales sin detalles / transparencia proporcionada al DBA. El servidor host cambiará dinámicamente la configuración de las máquinas invitadas, lo que provocará una caída en el rendimiento y dejará al DBA sin una pista. Las características como el hypertreading, el trabajo en equipo de la red y los globos de memoria hacen que los contadores de rendimiento sean un objetivo en movimiento para monitorear.Tools: sysmon/perfmon, DMVs, maintaining a history of performance counters in tables.
2. Del mismo modo, no hay transparencia / verificabilidad en la configuración de SAN proporcionada al DBA. He tenido LUN con diferentes preferencias de caché de lectura / escritura establecidas, pero me dijeron que eran todas iguales.Tools: IO DMVs, SQLIO.
3. Mala arquitectura de la base de datos: como el tamaño y la ubicación de los datos y los archivos de registro, y tempdb. Uso incorrecto del paralelismo. Crear múltiples grupos de archivos en los mismos discos físicos.Tools: experience.

Otra herramienta que estoy revisando ahora es el Proyecto Lucy . Parece ordenado

• falta de índices adecuados
• uso de nolock en el código de producción por alguien para tratar de resolver problemas de rendimiento. Especialmente malo si el código modifica datos en tablas
• aplicación que selecciona más datos de los necesarios en más momentos de los necesarios. Ex que se devuelva un binario cada vez, incluso si solo desea los datos de texto de la misma tabla.

Consultas que escalan mal (obtenga todos los pedidos por X años para todos los clientes, etc., incluidas todas las líneas de pedido, incluidos los datos sumados y otros datos promedio mal calculados)

Solo consulta todo a la vez.

Tablas que contienen campos de texto / varchar 'descriptos' que deben buscarse en cada consulta.

• Mantenimiento inadecuado, es decir, sin reorganizaciones de índices, estadísticas, sin copias de seguridad de registros
• Índices faltantes
• Consultas mal escritas

• Base de datos y diseño de aplicaciones deficientes.
• mal uso de las ventajas de la plataforma (los desarrolladores querían tener un código de acceso a la base de datos integrado en la plataforma. Sin SP, sin funciones, etc.)
• mala indexación, por supuesto.

• consultas ad-hoc sobre datos de producción: sí, los desarrolladores creen que es necesario y algunos incluso pueden tener acceso :-)
• mal diseño de la aplicación que utiliza la base de datos, por ejemplo: demasiados datos agregados y nunca eliminados, incluso si ya no son necesarios (lo que lleva a problemas de rendimiento porque las copias de seguridad crecen, las tareas de mantenimiento toman más tiempo ... etc.)
• todos los archivos de base de datos en la misma incursión o peor, en la misma unidad (por ejemplo: dbs del sistema, tempdb, dbs del usuario, todos juntos en la misma unidad / incursión)

• Diseño deficiente de la base de datos
• Estrategia de indexación deficiente (incluidos demasiados índices, índices faltantes y falta de mantenimiento del índice)
• Decisiones de arquitectura de hardware deficientes

La indexación es crítica para el rendimiento, pero descubrí que la mayoría de los DBA lo saben, por lo que tiende a ser una de las primeras cosas que se soluciona mediante la optimización de consultas. Las áreas que a menudo no están bien abordadas:

1. Demasiados viajes de ida y vuelta a DB. Chattiness es uno de los principales problemas de rendimiento que veo.
2. Obteniendo los límites de transacción correctos. La transacción de cada INSERTAR / ACTUALIZAR / ELIMINAR puede ser un gran asesino de rendimiento.
3. Fracaso para optimizar el lado del hardware; particularmente, colocando el registro de DB en un volumen diferente de los datos de DB.

Si pudiera agregar un cuarto elemento a la lista, sería un uso excesivo e inapropiado de disparadores y / o cursores. No parece suceder demasiado en estos días, pero cuando sucede, es doloroso desde una perspectiva de rendimiento.