Curso GRATIS SQL Server en Docker

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


SQL Server performance: ORDER BY y consumo de CPU

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

Video explicativo

Links adicionales

SQL Sentry Explore Plan

SQLQueryStress

Material Webinar SQL 2019

El pasado 6 de abril de 2020 he impartido un webinar donde hice un repaso de las novedades de SQL Server 2019 , sus distintas opciones de despliegue, una demo de ADR y tips para migrar a la nueva versión.

Comparto el video completo del webinar como así también la presentación .

 

Webinar SQL Server 2019

Webinar SQL Server 2019

El próximo 6 de abril de 2020 estaré impartiendo un Webinar gratis de modernización con SQL Server 2019.

En el mismo veremos.

  • Opciones de deploy (Windows, linux, docker, azure)
  • Repaso de las nuevas funcionalidades de SQL Server 2019
  • Que cambios hay en la edición standard.
  • Como encarar un proceso de migración para tu empresa

Para más información en en siguiente botón puedes acceder al avento.

SQL 2019: Optimización de la metadata en la Tempdb

SQL 2019: Optimización de la metadata en la Tempdb

Todo DBA de SQL Server sabe lo importante que es la base de datos Tempdb. Conocemos que tenerla bien configurada nos asegura no tener un cuello de botella en performance para esta base de datos tan importante dentro de nuestro motor.

Desde hace años hay varias recomendaciones para evitar la contención en la metadata de la tempdb como por ejemplo:

  • Crear tantos Datafiles como cores exista (hasta 8)
  • Habilitar los TF 1117 y 1118 si la versión es menor a SQL Server 2016 (en esta última viene activo por defecto).

En las últimas versiones de SQL Server el propio instalador (setup) hacia las recomendaciones necesarias para esta base de datos ya que en muchas ocasiones los DBA no la configuraban según las buenas practicas.

SQL Server 2019

En SQL Server 2019 se ha dado un paso mucho más importante y es la posibilidad de que la metadata de la tempdb este 100% en RAM como una tabla in-memory del In-memory OLTP que ya existe desde versiones anteriores.

Obviamente que tener la metadata de la TempDB en memoria hará que ya no sea más un problema ni cuello de botella la creación y recreación de objetos, recordemos que esta base de datos tiene la particularidad que se crean y borran objetos todo el tiempo.

En este post vamos a probar el funcionamiento de esta nueva funcionalidad de SQL Server 2019, en mi caso usare una imagen de docker de SQL Server 2019 sobre Ubuntu , si quieres saber como instalarlo aca te dejo un post

Paso 1:

Lo primero que vamos a chequear que la nueva funcionalidad viene deshabilitada por defecto , para chequear el estado vamos a ejecutar el siguiente código TSQL 

SELECT 
SERVERPROPERTY('IsTempDBMetadataMemoryOptimized') AS
IsTempDBMetadataMemory; 

Paso 2:

Crearemos una base de datos nueva con un simple Store Procedure el cual generar tablas temporales

IF NOT EXISTS (SELECT NAME FROM SYS.DATABASES WHERE NAME='TRIGGERDBDEMO')

CREATE DATABASE TRIGGERDBDEMO 
USE TRIGGERDBDEMO
GO

CREATE OR ALTER PROCEDURE DBO.USP_SQL2019TEMPDB AS
  CREATE TABLE #TEMP1 (ID INT IDENTITY PRIMARY KEY,
                       NAME CHAR(50),
                       FECHA DATETIME)

GO 

Paso 3:

Lo que probaremos ahora es una carga de stress llamando muchas veces al Store Procedure que hemos creado antes.

Para poder hacer dicha carga de stress usaremos Ostress.exe de las RML utility las cuales puedes descargar de este link

Abriremos la línea de comandos y ejecutamos el siguiente código

c:\> ostress.exe -Slocalhost,15000 -Usa -PPassw0rd///  -dTriggerdbDEMO -Q”EXEC DBO.USP_SQL2019TEMPDB”  -mstress -quiet -n50 -r1000

Si mientras ejecutamos el stress queremos monitorear las contenciones en la tempdb podríamos usar el siguiente código

USE tempdb
GO
SELECT object_name(page_info.object_id), page_info.* 
FROM sys.dm_exec_requests AS d 
CROSS APPLY 
sys.fn_PageResCracker(d.page_resource) AS r 
CROSS APPLY 
sys.dm_db_page_info(r.db_id, r.file_id,r.page_id,'DETAILED') AS page_info

El tiempo para nuestra prueba de stress fue de 38 segundos.

Paso 4:

Ahora vamos a activar y usar la nueva funcionalidad de SQL Server 2019 para que la metadata de la tempdb resida en memoria, para ello debemos seguir estos pasos.

ALTER SERVER CONFIGURATION SET MEMORY_OPTIMIZED TEMPDB_METADATA=ON;

Reiniciar el servicio de SQL Server, en mi caso como estoy usando un contenedor voy a reiniciar el container de la siguiente forma:

c:\> docker restart fe139cdee3eb

Luego del reinicio nos conectaremos a nuestra instancia para verificar que haya quedado activo de forma correcta ejecutando el siguiente código y verificando que el resultado sea 1

SELECT 
SERVERPROPERTY('IsTempDBMetadataMemoryOptimized') AS
IsTempDBMetadataMemory; 

Ahora volvemos a ejecutar nuestra prueba de Ostress

c:\> ostress.exe -Slocalhost,15000 -Usa -PPassw0rd///  -dTriggerdbDEMO -Q”EXEC DBO.USP_SQL2019TEMPDB”  -mstress -quiet -n50 -r1000

En mi prueba ahora el proceso demoró 16 segundos vs los 38 originales, pero además de ello bajaron casi a 0 las contenciones dentro de mi Tempdb

Conclusiones

Ya desde hace varias versiones atrás SQL Server viene incorporando distintas funciones in-memory con el objetivo de poder mejorar la performance. La de la metadata de Tempdb es otra mas de ellas que habrá que analizar si como DBA´s la activamos o no, siempre debemos considerar que se debe analizar el consumo de memoria RAM y ver si tenemos los recursos suficientes para poder poder esta funcionalidad


SQL 2019 RTM en Docker

En el siguiente post vamos a instalar un SQL Server 2019 RTM sobre docker de Windows. 

Pre requisitos

Paso 1: Bajar la imagen

Como primer paso lo que debemos hacer es bajar la imagen de SQL Server 2019 RTM, en este caso bajaremos la imagen de Linux Ubuntu
c:> docker pull mcr.microsoft.com/mssql/server:2019-GA-ubuntu-16.04

Paso 2: Crear un contenedor con SQL 2019  RTM

Cuando ya tengamos la imagen descargada podemos iniciar un contenedor , en mi caso usare el puerto externo 15000
c:> docker run -e "ACCEPT_EULA=Y" -e "SA_PASSWORD=Passw0rd///" -p 15000:1433 --name sql2019 -d mcr.microsoft.com/mssql/server:2019-GA-ubuntu-16.04

Paso 3: Conectarnos a nuestro contenedor

Para poder conectarnos a nuestro contenedor con SQL Server 2019 RTM podemos usar cualquier herramienta cliente, en mi caso lo hare con SSMS
También podemos ejecutar el siguiente código TSQL para verificar algunos datos
SELECT 
SERVERPROPERTY('ProductVersion') as Build,
SERVERPROPERTY('ProductLevel') as Level,
SERVERPROPERTY('Edition') as Edition

Eliminar el contenedor

Para eliminar nuestro contendor deberíamos ejecutar el siguiente código desde la línea de comandos
c:> docker stop sql2019
c:> docker rm sql2019