SQL Server 2016 Setup y la Tempdb


La tempdb es bastante importante para el buen funcionamiento de las base de datos, esta debe de tener algunas características que ya hemos tocado anteriormente en otro post. Basándose en estas recomendaciones el nuevo instalador de SQL Server ahora nos permite configurar en la instalación algunos de estos valores.

Hoy en via veremos esto cuando llegamos a cierta parte de la instalación de SQL Server 2016 a partir de CTP3.




Aqui podemos ver que nos da un número de data files igual al número de procesadores (en mi caso es una A2 de Azure así que solo tengo 2), me permite poner un tamaño inicial al data file y al log file y un crecimiento, así como especificar donde estaran ambos archivos.

Para evitar contenciones se recomienda que el data file y el log file esten en una unidad distinta en ambientes que tengan un gran uso de IO, también no existe gran ganancia en usar un SSD en los logs, debido a que estos se escriben de manera secuencial contrario a random como lo es un data file, son consideraciones importantes que tenemos que tener en cuenta.

Pero...

Tenemos una limitante importante, si queremos crear por citar un ejemplo un tamaño inicial de 20gb y tenemos 8 data files serian 160gb que provicionemos, lo cual puede tomar tiempo debido a este pequeño comportamiento tenemos una limitante tanto en el crecimiento como en los log files de 256mb como tamaño inicial máximo, el cual debiera de ser modificado una vez tengamos la instancia funcionado.

Comentarios

  1. Hola, que hacerte una pregunta. Que recomendacion me das para un server con 8 procesadores?? Creamos 8 archivos para la tempdb?? de que tamaño inicial y que tipo de crecimiento?? Un saludo. Gran Blog!!

    ResponderBorrar
    Respuestas
    1. 8 Procesadores seria lo ideal como inicial, es físico? que versión de sql server, sobre el crecimiento y tamaño inicial ve los primeros días que uso tienes y hasta donde creces y basarte en esto para dar el valor inicial para tu ambiente.

      Borrar
  2. si , es un fisico con 2 instancias de 2012 y 1 instancia de 2016

    ResponderBorrar
    Respuestas
    1. No es recomendado que tengas múltiples instancias en el mismo server (entiendo que por costos se hace) en este particular caso me supongo que no estas asignado procesadores ni modificando las asignaciones de los mismo, por mejor practica te diría que 8 tempdb files por instancia seria aun lo recomendado.

      Borrar
    2. Efectivamente es un tema de costes. Creare las 8 temps por instancia. LO que tengo mis dudas es con valores iniciales seria lo optimo...Para ir empezando , luego una vez que analicemos los crecimientos las modificariamos.

      Borrar
    3. Puedes dejar el default, toma una semana y ve no existe un valor realmente que te pueda dar, veras algunos opinan que un % del total de dbs, etc pero considero que son aproximaciones que solo aplican cuando no sabes, lo que si dale algo inicial como 100mb y un crecimiento apropiado no 1% ponle 50mb o 100mb.

      Borrar
  3. Hola, realicé la migración de un sql 2008r2 a la version 2016 enterprise sin embargo el rendimiento de esta última en actualizaciones masivas en mucho menor a la 2008 a pesar que la nueva instancia tiene el doble de memoria RAM, de hecho he notado que Store Procedure que tienen varias actualizaciones en más de 3 millones de datos se queda pegado, los tempdb se crearon los 8 con un tamaño inicial de cada uno de 6.10gb para un total de 48.8 GB, el equipo tiene Windows server 2012 r2 en 64 Que puedo hacer?

    ResponderBorrar
    Respuestas
    1. Normalmente las inserciones son más Io que RAM, primero 2016 tiene configuraciones específicas, que nivel de compatibilidad está tu base? Cuántos y que tipos de Offices tocas en las inderciones

      Borrar
    2. el nivel de compatibilidad es 130 que es el del 2016, no entiendo la segunda consulta

      Borrar
    3. Para dar más especificaciones en el mismo server de SQL tengo un servidor de reporting service instalado, la base de datps está dividida en 2 unidades las cuales tienen discos fisicos diferentes y están configuradas en raid 5, el modelo de recuperacion que tiene es el simple. SI he notado o me da la impresión que cuando el log crece a cierto punto se pega lo cual me extraña, en la instancia anterior que era 2008 r2 y en 32 bits esto no era problema y lo más raro es que se revisa en el monitor y esta Running y no presenta bloqueo

      Borrar
    4. Perdona me tomaste en la noche y del celular aumenta mi ya de por si pobre ortografía.

      Mencionaba que las inserciones normalmente son altas en recursos, principalmente IO, mas que de RAM aunque ambos son usados.

      Cuantos indices tienes en tus bases que tiempo toma y que te refieres con pegado?

      Haz visto si tienes bloqueos?

      Borrar
    5. gracias, la base de datos tiene más de 300 tablas y cada una puede tener mas de 2 indices, en inserciones o actualizaciones masivas dura demasiado tiempo, hasta el triple que el server anterior que tenía menos memoria, no genera bloqueos solo indica que está running. Lo que me refiero con pegado es que dura el tripe que el server anterior teniendo más recursos que el anterior empezando porque el anterior era de 32bit y este de 64 además de tener 2 arreglos de discos diferentes en raid 5 y la base está dividida en archivos y están separados lo cual debería permitirme el paralelismo en las ejecuciones

      Borrar
    6. Raid 5 es demasiado lento y no recomendado para bases de datos altamente transaccionales, seria mejor un raid 1, tu caso parece un poco complejo si me contactas en lync a enriarg te podria ayudar, disculpa la tardanza dia ocupado

      Borrar
  4. una de las diferencias que tiene con el server anterior es que no se creó una unidad para paginación porque según microsoft no es necesario por la cantidad de memoria que posee actualmente el server nuevo que son 32GB

    ResponderBorrar

Publicar un comentario

Entradas más populares de este blog

Mover indices no clustered a un nuevo filegroup