Tutorial: SQL Query Stress Tool

SQL QUERY STRESS TOOL
En el siguiente tutorial te muestro como usar la herramienta gratuita SQL query Stress la cual podes descargar de la siguiente dirección
SQL QUERY STRESS TOOL
En el siguiente tutorial te muestro como usar la herramienta gratuita SQL query Stress la cual podes descargar de la siguiente dirección
En este post te voy a mostrar como podes configurar el modo oscuro en tu SSMS (SQL Server Management Studio)
Lo primero que vamos a hacer es acceder al menú de SSMS para observar que el modo DARK no se encuentra entre las opciones disponibles
Para ello accedemos al menú: Tools –> Options
Como podemos observar en la imagen el modo DARK no aparece entre las opciones.
Paso 1: Cerramos nuestro SSMS
Paso 2: Buscamos el archivo “ssms.pkgundef” en donde tengamos instalado nuestro SSMS, en mi caso estoy usando el SSMS 18 y la ruta es la siguiente: C:Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE
Paso 3: Copiamos el archivo “ssms.pkgundef” a otra ubicación
Paso 4: Con el bloc de notas editamos el archivo que hemos copiado y buscamos dentro del mismo la sección // Remove Dark theme
Paso 5: Modificamos la línea agregando un // quedando de la siguiente forma
Paso 6: Guardamos el archivo.
Paso 7: Reemplazamos el archivo original de C:Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE con este nuevo que hemos modificado.
Paso 8: Abrimos nuestro SSMS y vamos a al menu Tools –> Options y seleccionamos el modo oscuro
Ya tenemos nuestro modo DARK activo
No te olvides de seguirme en mis redes sociales
La performance de nuestro código TSQL es fundamental para que nuestras aplicaciones funcionen no solo de forma eficiente sino que también podamos reducir costos de HW o bien en los servicios de la nube.
Siempre la performance fue un tema a tratar en nuestras bases de datos MSSQL pero hoy día muchas empresas que migran a la nube y no tienen su base optimizada lo terminan pagando con mayores costos mensuales en los servicios que contratan.
Les dejo este webinar que di hace un tiempo en donde muestro algunos tips de performance en T-SQL que pueden ser de utilidad.
No olvides de seguirme en mi canal de Youtube o en nuestro grupo de Facebook para DBA de habla hispana
Les comparto este excelente ebook gratuito sobre la administración de bases de datos en Azure en el cual encontrarán los siguientes capítulos.
Uno de los ANTI-PATRONES (malas prácticas) de performance más frecuente es no utilizar consultas que tengan una expresión SARGS, lo cual impactará de forma notoria en la performance de nuestros procesos.
En este artículo te voy a contar que son las expresiones SARGS y veremos varios ejemplos de estos anti-patrones con su respectivo impacto en la performance.
Sargable es una palabra que está compuesta por tres palabras : búsqueda, argumento y capaz.
En otras palabras, SARGable se define como “En las bases de datos relacionales, se dice que una condición (o predicado) en una consulta es sargable si el motor DBMS puede aprovechar un índice para acelerar la ejecución de la consulta.
El término se deriva de una contracción de Search ARGument ABLE
Las ventajas de usar consultas SARGS son:
Para mis ejemplos utilizaré la base de datos AdventureWorks la cual podras descargar del siguiente link
https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks
Usar funciones en los campos de los WHERE hará que nuestra consulta no sea SARG compatible y por ende no se usen los índices de forma eficiente.
Veamos los siguientes ejemplos
SELECT * FROM Person.Person
WHERE LastName = 'Miller'
SELECT * FROM Person.Person
WHERE LEFT(LastName,4) = 'Mill'
SELECT * FROM Person.Person
WHERE upper(LastName) = 'MILLER'
Ahora vamos a analizar los planes de ejecución de cada una de nuestras consultas
Como se puede observar la consulta 1 que si es SARGS usa de forma eficiente el indice (Index Seek), pero en cambio la consulta 2 y 3 como no son SARGS no lo están usando de forma eficiente (Index Scan)
Veamos que significa esto en numeros de costos de recursos.
Consulta | Costo Total Query Plan | Costo CPU | Costo I/O |
---|---|---|---|
1 | 0.28 | 0,0135 | 0.263 |
2 | 0.40 | 0.0363 | 0.365 |
3 | 0.39 | 0.0363 | 0.361 |
Hagamos ahora una prueba de stress de performance con nuestras 3 consultas para ver que sucede, para eso voy a utilizar la herramienta gratuita SQLQueryStress con cada una de las consultas usando 50 hilos y 50 iteraciones
Como se puede observar en las pruebas de stress también vemos impacto en los tiempos del proceso y consumos de recursos.
Ahora vamos a ver otro ejemplo más donde usamos funciones en los WHERE pero con fechas.
Para eso veremos estas dos consultas las cuales retornan los mismos resultados.
SELECT SalesOrderID,OrderDate
FROM Sales.SalesOrderHeader H
WHERE OrderDate > = '20110101'
AND OrderDate < '20120101'
SELECT SalesOrderID,OrderDate
FROM Sales.SalesOrderHeader H
WHERE YEAR(OrderDate) = '2011'
Ahora vamos a observar los planes de ejecución donde veremos que la consulta 1 utiliza el índice de forma eficiente mientras la consulta 2 no lo hace
La siguiente tabla muestra los costos y consumos de la consulta 1 y 2 en donde se puede observar un consumo mucho mayor en la consulta 2 que en la 1, esta tabla es más grande que la del ejemplo anterior.
Consulta | Costo Total query Plan | Costo CPU | Costo I/O |
---|---|---|---|
1 | 0.0072 | 0.0019 | 0.0053 |
2 | 0.098 | 0.034 | 0.060 |
En este otro ejemplo veremos el uso de la función ISNULL en el WHERE y ver que sucede con SARG
Para este ejemplo primero vamos a crear un índice nuevo en nuestra tabla Person.Person
DROP INDEX IF EXISTS IX1 ON Person.Person
CREATE INDEX IX1 ON Person.Person(MIDDLENAME)
Ahora veremos estas dos consultas que retornan los mismos resultados, pero en la primera usamos el ISNULL en el WHERE y en la segunda no.
SELECT BusinessEntityID,MiddleName
FROM Person.Person
WHERE ISNULL(MiddleName,'A')='A'
SELECT BusinessEntityID,MiddleName
FROM Person.Person
WHERE (MiddleName IS NULL OR MiddleName ='A')
Observemos ahora cada plan de ejecución y sus costos
Consulta | Costo Total Query Plan | Costo CPU | Costo I/O |
---|---|---|---|
1 | 0.052 | 0.022 | 0.030 |
2 | 0.027 | 0.020 | 0.016 |
Aquí también podemos observar que la consulta 1 no es SARG y por ende hace un scan del indice siendo mas costoso que la consulta 2
Otra de las situaciones que hacen que una consulta no sea SARG es que se utilicen operadores en los campos del WHERE.
Vamos a analizarlo con ejemplos como los casos anteriores.
Para este ejemplo usaremos la tabla Sales.SalesOrderDetail de nuestra base de datos de ejemplo.
Primero creamos un índice como el siguiente:
DROP INDEX IF EXISTS IX_2 ON
[Sales].[SalesOrderDetail]
CREATE NONCLUSTERED INDEX IX_2 ON
[Sales].[SalesOrderDetail] (
[UnitPriceDiscount]
)
INCLUDE (
[ProductID],
[UnitPrice],
[OrderQty]
);
Luego vamos a probar las siguientes consultas y observar sus planes de ejecución / consumos
SELECT
[ProductID],
[UnitPrice],
[OrderQty]
FROM Sales.SalesOrderDetail
WHERE UnitPriceDiscount + 0.10 >= 0.30 -- no es SARG compatible
GROUP BY
[ProductID],
[UnitPrice],
[OrderQty]
SELECT
[ProductID],
[UnitPrice],
[OrderQty]
FROM Sales.SalesOrderDetail
WHERE UnitPriceDiscount >= 0.20
GROUP BY
[ProductID],
[UnitPrice],
[OrderQty]
Consulta | Costo Total Query Plan | Costo CPU | Costo I/O |
---|---|---|---|
1 | 0.66 | 0.138 | 0.52 |
2 | 0.025 | 0.0096 | 0.0156 |
Como se puede observar la primer consulta al no se SARG compatible tiene un mayor costo por usar el índice en modo Scan,
Los JOINS no se quedan atras tambien de estas prácticas, si aplicamos comandos no SARG en los ON vamos a ver un impacto en la performance.
Veamos las dos siguientes consultas donde ambas dan los mismos resultados pero en una no usamos SARG compatible y por ende cambiará nuestro plan de ejecución.
SELECT p.ProductID,
p.Name AS ProductName,
c.Name AS Category,
s.Name AS SubCategory
FROM Production.Product AS p
inner JOIN Production.ProductSubcategory AS s
ON p.ProductSubcategoryID = s.ProductSubcategoryID
INNER JOIN Production.ProductCategory AS c
ON s.ProductCategoryID + 10 = c.ProductCategoryID + 10
SELECT p.ProductID,
p.Name AS ProductName,
c.Name AS Category,
s.Name AS SubCategory
FROM Production.Product AS p
inner JOIN Production.ProductSubcategory AS s
ON p.ProductSubcategoryID = s.ProductSubcategoryID
INNER JOIN Production.ProductCategory AS c
ON s.ProductCategoryID = c.ProductCategoryID
Consulta | Costo Total Query Plan | Costo CPU | Costo I/O |
---|---|---|---|
1 | 0.065 | 0.0420 | 0.0212 |
2 | 0.053 | 0.0298 | 0.0212 |
La utilización de los anti-patrones que vimos los cuales hacen que una consulta TSQL puede ser SARGS compatible tiene impactos muy negativos en nuestros consumos de recursos y performance en general.
En mis años de experiencia veo de forma recurrente estas malas prácticas en el código TSQL las cuales sugiero siempre corregir en mis clientes.
Recuerden que más allá de los tiempos y consumos, si estamos en Azure por ejemplo vamos a estar gastando más dinero por no tener optimizados nuestro código.
Los contenedores han llegado para quedarse dentro del mundo de IT.
SQL Server y desde su versión 2017 ya se puede instalar en Docker .
En nuestro academia he armado un curso completamente gratuito y bajo demanda donde podrás aprender sobre como usar SQL Server sobre Docker.
En el mismo veras algunos conceptos teóricos y luego varios ejercicios paso a paso en donde podrás obtener mejores conocimientos aprendiendo haciendo.
Te dejo el siguiente enlace donde podrás acceder al mismo https://academia.triggerdb.com/p/workshopdocker