Brent Ozar lo sabe todo acerca de ir rápido:corre autos y acelera los servidores SQL con impresionantes resultados de rendimiento de la base de datos todos los días. En su webcast "Cómo medir SQL Server", para la serie de días de capacitación sobre bases de datos de Quest, Brent nos recordó que el rendimiento tiene que ver con la medición.
Aceleración para el rendimiento
Brent aprovechó la oportunidad para practicar el distanciamiento social y se vistió con un traje completo de carrera y un casco. En algunas bromas previas a la transmisión por Internet, nos enteramos de que tenía que conectar un micrófono al casco y pegar los auriculares con cinta adhesiva a sus oídos. Pero nos desviamos. El webcast se centró en el rendimiento y hubo muchas analogías de automóviles para todos.
Para mejorar el rendimiento de SQL Server, las premisas son:
- Elija métricas para centrarse en mejorar
- Mida el rendimiento antes y después de realizar cambios limitados (método científico básico)
- Comprenda cuándo tiene el equipo inadecuado para lo que está tratando de lograr
Métricas de ajuste del rendimiento de la base de datos
Una larga discusión sobre las camionetas Ford F150, Ford Fiestas y algunos otros vehículos interesantes ilustró que hay diferentes formas de mejorar el tiempo que se tarda en pasar de 0 a 60 millas por hora. Puede reducir el peso del vehículo, agregar un motor más grande o comenzar a eliminar elementos no esenciales, como un parabrisas. Va a haber un compromiso entre el rendimiento y la utilidad. Las bases de datos son así:a menudo se descargan. Aquí es cuando se necesita un ajuste de rendimiento personalizado, lo que requiere conocer y mejorar las métricas.
Brent sostiene que hay tres métricas principales que necesita para ajustar el rendimiento de los autos y las bases de datos:peso, punto de referencia de velocidad (como 0 a 60) y qué tan duro está trabajando el motor (servidor).
Medir el tamaño de la base de datos
El peso para SQL Server se traduce en el tamaño total de la base de datos y la cantidad de datos que tiene. Esto generalmente se mide en gigabytes o terabytes. Desde aproximadamente 1 a 150 GB, SQL Server Standard Edition debería ser suficiente. De 150 a 500 GB es una carga fácil para Enterprise Edition. Más allá de 500 GB, comienza a importar si se trata de datos activos y cómo se accede a ellos. Y cualquier cosa que supere 1 TB de datos OLTP podría ser muy desafiante.
Velocidad de rendimiento de seguimiento
El punto de referencia de velocidad en los automóviles es fácil:MPH. Para la base de datos, son solicitudes por lotes por segundo, pero esto debe tener una tendencia cada hora durante diferentes períodos de tiempo. Obviamente, cuantas más consultas haya, más lento será el rendimiento dependiendo del hardware.
Evaluación de cargas de trabajo de consultas
Finalmente, para comprender qué tan duro está trabajando la base de datos, debe comprender qué consultas se están ejecutando actualmente y qué está esperando en la cola. Esto le dará una relación de tiempo de espera:básicamente, cuánto tiempo esperan las tareas para que otras se completen. Su relación de tiempo de espera se expresará como horas de tiempo de espera por hora (o segundos de tiempo de espera por segundo); no mezcle sus unidades de medida. Cuando maneja bien estas estadísticas a lo largo del tiempo, puede ver qué afecta el tiempo de espera, por ejemplo, si hay más o menos solicitudes por lotes, consultas mejor o peor ajustadas, etc. Luego, puede abordar esos problemas.
Mire la grabación del seminario web a pedido para conocer todos los sabios consejos y el humor de Brent.
