Cuando escribimos nuestro código T-SQL en algunas ocasiones se observa la instrucción ORDER BY la cual técnicamente lo que hace es ordenar el set de datos resultantes y a menos que exista un TOP lo único que se logra es solamente una presentación de los datos.
Ahora bien, ¿ sabemos el impacto que esto tiene en la performance y el consumo de recursos ? , en este post te voy a mostrar que es lo que sucede cuando aplicas un ordenamiento y cuales serian las posibles alternativas de solución.
Ejemplo 1
Vamos a suponer que tenemos las siguientes consultas T-SQL
SELECT *
FROM PURCHASING.PURCHASEORDERHEADER
SELECT *
FROM PURCHASING.PURCHASEORDERHEADER
ORDER BY ORDERDATE
Si observamos sus planes de ejecución nos encontraremos el siguiente resultado:
Nota: Como se puede observar la segunda consulta tiene una operación adicional y además han aumentado sus costos en consumo de recursos (sobre todo CPU) con relación a la primer consulta.
Ejemplo 2
Supongamos los dos siguientes ejemplos en donde armamos una consulta pero ahora con un WHERE sobre un campo que tiene índices en la tabla.
SELECT *
FROM PURCHASING.PURCHASEORDERHEADER
WHERE EMPLOYEEID = 25
SELECT *
FROM PURCHASING.PURCHASEORDERHEADER
WHERE EMPLOYEEID = 25
ORDER BY ORDERDATE
Si observamos los planes de ejecución nos encontraremos con algo similar al ejercicio anterior
Nota: Podemos observar que por mas que se use el índice nos aparece en la segunda consulta el operador de SORT
Como evitar el operador SORT
La única forma de evitar este operador es creando un índice que contenga las columnas (claro la pregunta es si vale la pena hacer esto cuando en muchos casos es solo por presentación el uso de ORDER BY)
CREATE INDEX IX1 ON
PURCHASING.PURCHASEORDERHEADER (EMPLOYEEID,ORDERDATE)
Si ahora volvemos a correr la consulta anterior veremos el cambio en nuestro plan de ejecución donde no solo no esta el operador SORT sino que su costo a bajado
Conclusiones finales
Usar un ORDER BY cuando no tenemos un TOP no tiene mucho sentido y genera un consumo mas alto de recursos en nuestro servidor de base de datos, sobre todo CPU (recordemos que por este recurso es como se nos cobra tanto en licencias o azure)
Crear índices para solo ordenar suele ser una muy mala idea, básicamente porque vamos a penalizar las operaciones de insert, update , delete o merge.
Esta práctica del ORDER BY la he visto en mucho código TSQL a lo largo de mis años haciendo optimizaciones, yo recomiendo evitarla por completo y si hay un TOP en ese caso si crear el índice correspondiente
En varias ocasiones hemos tenido la necesidad de mover nuestros archivos de la base de datos Tempdb a otra ubicación , por ejemplo si nos hemos quedado sin espacio, si la hemos alocado originalmente en un lugar inadecuado , etc.
En este post te muestro los pasos que debes seguir para mover tus archivos de Tempdb a otra unidad.
Paso 1: Conocer su ubicación actual y sus nombres
En este primer paso lo que haremos es buscar los nombres lógicos y su ubicación actual en nuestros discos , para ello ejecutaremos el siguiente script
SELECT NAME, PHYSICAL_NAME
FROM SYS.MASTER_FILES
WHERE DATABASE_ID = DB_ID(N'TEMPDB')
El cual arroja un resultado similar a la siguiente imagen
En este caso podemos ver que tenemos 8 archivos de data y 1 de log, todos están ubicados en el disco E:\mssql
Paso 2: Modificar la ubicación de los archivos
En este paso lo que haremos es modificar la ubicación del o los archivos que necesitamos mover a otra ubicación, para eso usaremos el siguiente script
USE MASTER;
GO
ALTER DATABASE TEMPDB
MODIFY FILE (NAME = TEMPDEV, FILENAME = 'E:\SQLDATA\TEMPDB.MDF');
GO
ALTER DATABASE TEMPDB
MODIFY FILE (NAME = TEMP2, FILENAME = 'E:\SQLDATA\TEMPDB2.NDF');
GO
ALTER DATABASE TEMPDB
MODIFY FILE (NAME = TEMP3, FILENAME = 'E:\SQLDATA\TEMPDB3.NDF');
GO
ALTER DATABASE TEMPDB
MODIFY FILE (NAME = TEMP4, FILENAME = 'E:\SQLDATA\TEMPDB4.NDF');
GO
ALTER DATABASE TEMPDB
MODIFY FILE (NAME = TEMP5, FILENAME = 'E:\SQLDATA\TEMPDB5.NDF');
GO
ALTER DATABASE TEMPDB
MODIFY FILE (NAME = TEMP6, FILENAME = 'E:\SQLDATA\TEMPDB6.NDF');
GO
ALTER DATABASE TEMPDB
MODIFY FILE (NAME = TEMP7, FILENAME = 'E:\SQLDATA\TEMPDB7.NDF');
GO
ALTER DATABASE TEMPDB
MODIFY FILE (NAME = TEMP8, FILENAME = 'E:\SQLDATA\TEMPDB8.NDF');
GO
ALTER DATABASE TEMPDB
MODIFY FILE (NAME = TEMPLOG, FILENAME = 'F:\SQLLOG\TEMPLOG.LDF');
GO
Paso 3: Reiniciar el servicio de SQL Server
Para que se apliquen los cambios debemos hacer un reinicio de los servicios de SQL Server, luego de hacer este paso tendremos nuestro cambio realizado con exito.
Paso 4: Verificamos el cambio
Para verificar luego del reinicio que el cambio se ha aplicado simplemente debemos volver a ejecutar el script del paso 1
SELECT NAME, PHYSICAL_NAME
FROM SYS.MASTER_FILES
WHERE DATABASE_ID = DB_ID(N'TEMPDB');
El pasado 8 de julio de 2020 he impartido un Webinar gratuito en el que participaron 80 personas y he mostrado cómo implementar las auditorías nativas en SQL Server y azure Managed Instance.
En este post dejo el contenido del video, códigos de ejemplos y presentación.
Especialista y orador en Plataformas de datos Microsoft con más de 20 años de trayectoria 