¿Merecen la pena los indices columnares en SQL Server 2016?

Resulta que la implementación de los operadores en SQL Server 2014 y 2012 respecto a los índices columnares no era completa y que el generador de planes de ejecución no tenia algunas optimizaciones aplicadas al respecto además. Vamos, que en SQL Server 2014, tus tablas que tienes perfectamente indexadas con índice columnar, van a medio gas, a pesar de lo rápido que creas que van tus queries.

Continua leyendo…

Rendimiento de las funciones UDF en SQL Server 2016 (1/2)

En SQL Server 2016 podemos programar funciones escalares de usuario de 3 formas diferentes:

• T-SQL
• CLR
• De compilación nativa para In-Memory OLTP

A pesar de que tenemos varias formas de programar funciones, su uso principalmente está concentrado en la de tipo T-SQL, cosa que a mas de uno le va dar un poco de dolor de cabeza cuando lea esto

Continua leyendo…

Indexar claves ajenas

SQL Server por defecto no indexa una clave ajena y debemos ser nosotros los que lo hagamos. En este post verás un nuevo ejemplo de por qué es interesante tener siempre indexadas las claves ajenas.

Continua leyendo...

DBCC FREEPROCCACHE y sus peligros

El comando DBCC FREEPROCCACHE se encarga de borrar todos los planes de ejecución cacheados en la instancia (o uno en concreto si se especifica su handle específico). Este comando debe ser visto como lo que es, un comando para entornos de pruebas, pero nunca como un recurso a tener en cuenta en un entorno de producción.
Generalmente cuando alguien lee sobre este comando, acaba leyendo algo como lo que acabo de mencionar, en este caso me dispongo a mostrar qué ocurre cuando lo lanzamos en un sistema de producción real.

Continua leyendo...

Rendimiento tempdb mejorado en SQL Server 2014

Desde tiempos inmemoriales, hay un dicho que dice: “Usa siempre que puedas tablas temporales porque esas tablas viven en RAM”. A veces lo he oido con variables de tabla, pero la “esencia” del dicho es que puedes mejorar el rendimiento de lógica de negocio en por ejemplo procedimientos almacenados, creando objetos “temporales”. Nada mas lejos de la realidad :)
La realidad es que una tabla temporal o una variable de tabla, finalmente acaba escribiendose en disco…pero en los discos donde residen los ficheros de tempdb. Es decir, que si, que una tabla temporal o variable de tabla SI genera presión de E/S. ¡Sorpresa!
La buena noticia es que ese famoso “dicho” en SQL Server 2014 ya no es mentira del todo :).
CONTINUAR LEYENDO…

Forzar affinidad NUMA para SSIS

Es muy importante configurar correctamente la afinidad NUMA de una máquina que corre más de un servicio-aplicación intensiva. Hace algún tiempo escribí sobre paralelismo en SQL Server y debatimos entre algunas cosas sobre la importancia del afinamiento de CPU a la hora de obtener el máximo rendimiento de tu Hardware (puedes leer aqui: Paralelismo en SQL Server (I) )
El caso es que no en pocas ocasiones se me pregunta cómo puedes particionar el HW correctamente cuando usas SQL Server y otros servicios en la misma máquina. Obviamente la afinidad de procesador nativa de SQL Server nos va a servir claramente cuando tenemos por ejemplo 2 nodos numa y 2 instancias de motor relacional corriendo independientes en esa misma máquina.
CONTINUA LEYENDO…

SQL Server In-memory OLTP engine

Con la cada vez mas cercana salida a RTM de la próxima versión de SQL Server 2014, aparece un nuevo motor relacional. Su anterior nombre en clave “Hekaton” ha sido sustituido por uno que no da lugar a dudas “In-Memory OLTP”. Es un nuevo motor relacional optimizado para datos residentes en memoria y cargas de trabajo tipo OLTP. Téngase presente que este motor surge como la motivación en Microsoft, de llegar a aumentar 100 veces el rendimiento de SQL Server en entornos puramente OLTP.
El motor en memoria incluido en SQL Server 2014, al contrario de lo que ofrecen otros fabricantes se encuentra completamente integrado en el producto y por tanto no se trata de un sistema distinto. Se trata de un motor relacional completamente transaccional y persistente, que se utiliza exáctamente igual que el motor on-disk (mediante T-SQL) y que a simple vista, se encuentra completamente integrado en el producto, posibilitando una aparente transparencia a la hora de utilizarlo.
Aunque se trata de un motor completa y radicalmente diferente al actual, ambos motores se comunican perfectamente y se permite por ejemplo realizar consultas que toquen objetos (tablas por ejemplo) de tipo on-disk e in-memory de forma transparente.

Diagrama de comunicación entre el motor in-memory (aka “Hekaton” o “in-memory”) y SQL Components (aka on-disk)

Continuar leyendo…

Articulo publicado en la revista DotNetMania nº98

Ya puedes leerme en el número de diciembre de 2012 de la revista DotNetMania http://www.dotnetmania.com/ 

En una serie de 4 artículos, hablaré junto a mi compañero Enrique Puig sobre “Buenas prácticas de codificación para capas de acceso a datos de aplicaciones”. En esa serie de 4 artículos vamos a desmenuzar las distintas posibilidades que tenemos a la hora de enfrentarnos al desarrollo de capas de acceso a datos.

Hablaremos a grandes rasgos de: 

• Patrones de acceso a datos
• Tipología de acceso
• Patrones de bajo nivel
• ORM
• Motivación de los ORM
• Pros y contras de los ORM
• Entity framework
• Entity Data Model
• Operaciones con Entity Framework
• Comparativa de rendimientos

No te lo pierdas! suscribete a http://www.dotnetmania.com/ para poder disfrutarlos.

Monitorizando y optimizando problemas de paralelismo en SQL Server

He dejado en mi site público las diapositivas de mi sesión para las 24 horas de PASS libres para descarga. Aqui tienes las diapositivas para descarga: http://sdrv.ms/VrW1qh 

Te recuerdo que tengo compartidas la mayoría de mis sesiones públicas listas para descarga aqui: http://sdrv.ms/M4iPsr

Linked servers: optimización

Los servidores vinculados ó linked servers en SQL Server son una característica bastante utilizada en la mayoría de entornos actualmente.

El siguiente texto forma parte de la documentación oficial hablando de linked servers :

"To create the best query plans when you are using a table on a linked server, the query processor must have data distribution statistics from the linked server.Users that have limited permissions on any columns of the table might not have sufficient permissions to obtain all the useful statistics, and might receive a less efficient query plan and experience poor performance. If the linked server is an instance of SQL Server, to obtain all available statistics, the user must own the table or be a member of the sysadmin fixed server role, the db_owner fixed database role, or the db_ddladmin fixed database role on the linked server"

Y aquí por tanto nos está diciendo que debemos cumplir una premisa relativa a la seguridad del servidor vinculado. En el siguiente punto veremos qué implicaciones tiene el enunciado anterior.

¿Qué debemos tener en cuenta al utilizar un servidor vinculado?

Lo que debemos tener muy presente a la hora de utilizar un servidor vinculado es que si no cumplimos el requisito anterior, los valores de las estadísticas que se utilizan para generar el plan de ejecución que SQL Server genera son incorrectos y terminan produciendo un grave problema de rendimiento “desapercibido”.

La razón es ni mas ni menos, que se necesitan permisos sysadmin, db_owner o db_ddadmin del login remoto que se usa para logearse en el servidor remoto. De lo contrario, no se tienen permisos suficientes para poder acceder a las estadísticas de los objetos remotos y por tanto el plan de ejecución será generado con información incorrecta y potencialmente se generará ineficientemente.

El siguiente ejemplo ilustra bastante bien el problema y su solución

….

Si deseas leer más, accede al post original que se encuentra aquí:

http://blogs.solidq.com/ElRinconDelDBA/Post.aspx?ID=212&title=linked+servers%3a+optimizaci%c3%b3n

Optimiza con T-SQL 2012 y clausula OVER

SQL Server 2012 supone un gran salto para los desarrolladores que quieren ir un paso mas allá en la resolución de problemas con conjuntos de datos. En esta edición de SQL Server, existe un antes y un después a la hora de trabajar con los conjuntos de datos mediante T-SQL, y como puede correrse el riesgo de seguir utilizando T-SQL como “hasta ahora”, me he propuesto escribir este post para conseguir transmitir al lector, las importantes mejoras que aparecen y que pueden parecer insípidas si no se enfatizan, en el operador OVER.

Para entender mejor y darle todo el valor que merece la que para mi puede ser una de las mas importantes mejoras en en T-SQL 2012, creo conveniente recordar un aspecto clave en todo motor relacional: “Trabaja con conjuntos de datos”....

Para continuar leyendo, accede al post original: http://blogs.solidq.com/ElRinconDelDBA/Post.aspx?ID=205&title=Optimiza+con+T-SQL+2012+y+cl%c3%a1usula+OVER

Particionado en SQL Server (I/II)

Pese a que el particionado de datos apareció en SQL Server 2005, no he visto que los escenarios habituales de entornos OLTP incluyan el particionado de datos. Unas veces por desconocimiento, otras por miedo, el caso es que no es una característica que personalmente haya observado en las instalaciones como algo a tener muy en cuenta. Pese a que no se trate de una característica en la que haya que pensar habitualmente, es cierto que en bastantes ocasiones ha encajado como solución.

El particionado consiste en realizar una separación física de los datos de un objeto, para generalmente obtener rendimientos superiores en determinados tipos de consultas, como más adelante veremos (en siguiente post). Típicamente es una característica que se suele aprovechar en escenarios analíticos de BI al trabajar con Datawarehouses, pero también es factible su utilización en entornos OLTP para mejorar escenarios mediante la distribución física de los datos entre nuestros subsistemas de disco, por ejemplo…

Para continuar leyendo: http://blogs.solidq.com/ElRinconDelDBA/Post.aspx?ID=200&title=Particionado+en+SQL+Server+(I%2fII)

Webcast solución de problemas de rendimiento en SQL Server

Tengo el placer de impartir una formación técnica sobre solución de problemas de rendimiento en SQL Server el próximo dia 19 de Enero de 2011 a las 10am para formación de partners de Microsoft.
La url de registro directa es la siguiente: REGISTRO
¿De qué voy a hablar? Bueno, pues a modo de resumen, entre otras cosas hablare sobre:

• Configuraciones avanzadas de SQL Server
  • Threads vs fibers
  • NUMA
  • IO Affinity Mask
  • Max Degree of parallelism
• Configuraciones avanzadas de base de datos
  • Auto Update Statistics y Auto Update Statistics asynchronously
  • Date correlation optimization
  • Parametrization
• Reducción de idas y venidas mediante el uso de TVP
• Las funciones en SQL Server, el desastre y su solución

Todas ellas importantes cuando hablamos de rendimiento en SQL Server y que en ocasiones no se conocen todo lo bien que nos gustaria. Pretendo dar información útil para conocer un poco este tipo de configuraciones no muy utilizadas pero potentes.
Junto al mio, hay otros eventos que se realizan otros dias y que podeis ver en la siguiente web oficial: https://partner.microsoft.com/spain/40157196
Os espero!

Webcast solución de problemas de rendimiento en SQL Server

Tengo el placer de impartir una formación técnica sobre solución de problemas de rendimiento en SQL Server el próximo dia 19 de Enero de 2011 para formación de partners de Microsoft.

La url de registro directa es la siguiente: REGISTRO

¿De qué voy a hablar? Bueno, pues a modo de resumen, entre otras cosas hablare sobre:

• Configuraciones avanzadas de SQL Server
• Threads vs fibers
• NUMA
• IO Affinity Mask
• Max Degree of parallelism
• Configuraciones avanzadas de base de datos
• Auto Update Statistics y Auto Update Statistics asynchronously
• Date correlation optimization
• Parametrization
• Reducción de idas y venidas mediante el uso de TVP
• Las funciones en SQL Server, el desastre y su solución

Todas ellas importantes cuando hablamos de rendimiento en SQL Server y que en ocasiones no se conocen todo lo bien que nos gustaria. Pretendo dar información útil para conocer un poco este tipo de configuraciones no muy utilizadas pero potentes.

Junto al mio, hay otros eventos que se realizan otros dias y que podeis ver en la siguiente web oficial: https://partner.microsoft.com/spain/40157196 

Os espero!

Automatiza el análisis de contadores de rendimiento

Como bien sabe cualquier DBA, siempre conviene ser proactivo y parte de esa proactividad es la capacidad de analizar la información que proviene de nuestros sistemas de la forma mas útil posible.

En este caso me he decidido a escribir brevemente sobre un apartado que mucha gente no conoce del colector de contadores de rendimiento, su capacidad de almacenar la información en base de datos.

Si bien no quiero llevaros a pensar que es la práctica a seguir siempre (cada escenario es diferente), si quiero daros a conocer las posibilidades que tenemos de utilizar este enfoque, dado que es muy versatil.

Lo único que necesitamos es crearnos un DSN de sistema, que apuntaremos a la instancia y BBBDD donde queramos almacenar la información.

Para ello lo voy a enseñar con una serie de screenshots, que se ve claro:

1. Abrimos el administrador de origenes de datos ODBC y nos vamos a la pestaña “System DSN”

Figura 1

2. Seleccionamos el driver “SQL Server”

Figura 2

3. Configuramos su conexión como vemos en las figuras de la 3 a la 7. Nótese que debemos especificar una BBDD donde almacenar la información.

     La BBDD que pongamos, si no tiene las tablas donde almacenarse la información, en el proceso de configuración del colector de datos se creará. Si ya existian por el contrario, no se borrarán, se insertarán los datos sin más.

Figura 3

Figura 4-5

Figuras 6-7

4. Una vez hemos acabado de configurar nuestro DSN de sistema, procedemos ahora a configurar el colector de datos. Para ello abrimos el monitor de rendimiento (ver figura 8)

Figura 8

5. Nos vamos a definirnos un colector de usuario como se puede apreciar en las figuras 9 a la 12

Figuras 9-10

NOTA: En la figura 12 nos pide una ruta de disco local donde almacenar la información. Puesto que por defecto se crea así, le especificaremos una ruta, pero no será utilizada por lo que podemos dejarla como está

Figuras 11-12

6. Ahora es cuando realmente hacemos la parte “diferente” del proceso, puesto que configuraremos el colector para que en lugar de almacenar la información en formato binario en la ruta especificada anteriormente, le diremos que lo almacenaremos en base de datos, utilizando el DSN de sistema creado con anterioridad

 

Figura 13

Al pulsar sobre propiedades tal como se aprecia en la figura 13, pasamos a configurar el “log format”  indicando que lo deseamos en formato SQL (figura 14) y posteriormente indicamos el DSN de sistema que utilizará para almacenar la información (figura 15).

Figuras 14-15

7. Una vez pulsado en el botón de inicio de coleccionar datos, se procederá a la creación de objetos necesarios para ello en la BBDD destino

Figura 16

Figura 17

NOTA: Fíjese como ahora el Output es SQL:loquesea. Esto en otras configuraciones es una ruta a un fichero .blg

8. La última parte ya corre de vuestro lado. Quedaria por tanto explotar esa información (como podeis ver por ejemplo en el Code Snippet que os he dejado), reciclar la información, crear reportes, consolidar,…

Code Snippet

1. SELECT
2.   dtid.DISPLAYSTRING
3.             , cd.MACHINENAME
4.   , cd.OBJECTNAME
5. , cd.COUNTERNAME
6. , cd.INSTANCENAME
7. , cdta.COUNTERDATETIME
8. , cdta.COUNTERVALUE
9. FROM dbo.CounterData AS cdta
10.          INNER JOIN dbo.CounterDetails AS cd ON cdta.COUNTERID = cd.COUNTERID
11.          INNER JOIN dbo.DisplayToID AS dtid  ON cdta.GUID = dtid.GUID

Figura 18

Espero haberos dejado un buen punto de partida para “juguetear”

Salu2!

Detección de patrones de consulta ineficientes

Es bien sabido que como norma general, realizar una optimización de rendimiento a un sistema en producción no es tarea fácil. Cualquiera que ha trabajado en un proyecto de optimización ya se ha dado cuenta que cuando comienza, rara vez dispone de una zona acotada donde se encuentra el problema. En esencia, todo proyecto de optimización sea del ámbito que sea, conlleva una fase de análisis en la que detectar dónde está el problema.

Lo raro en este tipo de proyectos es por tanto encontrar situaciones en la que alguien nos comenta: “cuando pulsamos en este botón del formulario X, dados estos valores de entrada…todo va lento”. Esto no solo seria algo trivial, sino que como luego veremos, se trata de un caso particular que puede que no requiera por nuestra parte ningun estudio, con el fin de optimizar el sistema global.

Pero cuando el sistema que queremos optimizar incluye un motor de base de datos, todavía se complica más puesto que un escenario real, conlleva decenas de aplicaciones y cientos o miles de usuarios trabajando contra SQL Server, por lo que no resulta fácil conocer qué casos concretos están produciendo una merma de rendimiento, ya que esta puede venir tanto de la aplicación como del motor de base de datos.

A grandes rasgos, la primera y más importante tarea que debe llevarse a cabo a la hora de optimizar un sistema por tanto es ….

Si deseas seguir leyendo, te recomiendo que leas el journal gratuito (si, gratuito) Solid Quality Journal.

Para continuar leyendo, pincha en este enlace: http://www.solidq.com/sqj/Pages/Home.aspx?mentor=Enrique%20Catal%C3%A1&dates=October,%202010&enddatetime=2010-10-26T00:00:00&startdatetime=2010-10-24T00:00:00

Cuando salga la edición en castellano editada actualizaré este post: