Categoría: Sin categorizar

por Fran Lens 2020-04-02

Mejora aún más el rendimiento de Managed Instance

En la empresa llevamos ya más de 1 año trabajando con Azure SQL Database Managed Instance (Instancia Administrada) y en líneas generales podemos decir que estamos encantados, porque al ser una herramienta PaaS ya no tenemos que preocuparnos de incidencias en el hardware o actualizaciones, solo de problemas que puedan ocurrir en las bases de datos.

Antes de empezar a hablar de cómo mejorar el rendimiento de Managed Instance, deciros que si no conocéis bien esta herramienta, podéis ver la entrada de mi compañero Nacho Cotanda en la que explica su funcionamiento y enseña como crearla en Azure.

Como comentaba en la introducción, Managed Instance es una herramienta PaaS y eso nos permite olvidarnos de gran parte de la configuración, por lo que empecemos por enumerar las características y opciones que ya vienen totalmente optimizadas y de las que no tendremos que preocuparnos.

En Managed Instance no tienes que preocuparte de…

• Hardware compartido, como en toda la plataforma Azure, todos los recursos están reservados para ti, es decir los vCore, memoria ram o discos solo serán utilizados por tu Managed Instance.
• Actualizaciones, nunca más tendrás que preocuparte de nuevas versiones de SQL Server, Service Pack o Cummulative Update, se actualizará automáticamente y sin corte en el servicio.
• Copias de Seguridad, tendrás copias de seguridad automáticas de hasta 35 días de antigüedad y podrás restaurarlas con precisión de milisegundos (En próximas actualizaciones incorporarán Long-Term Backups).
• Alta Disponibilidad, todos los recursos de tu Managed Instance están replicados en varios nodos, por lo que se asegura una disponibilidad del 99,99%.
• TempDB, ya no tienes que estar pendiente del número de ficheros o tamaño porque se gestiona automáticamente.
• Max Server Memory, este valor que siempre era necesario ajustar ahora también se ajusta automáticamente.
• Fill Factor, tampoco tendrás que preocuparte del factor de llenado de tus índices, se ajusta automáticamente.
• Trace Flags, todas las trace flag que normalmente activarías ya están activadas, y muchas más, puedes comprobarlo ejecutando DBCC TRACESTATUS.
• Y paro aquí porque podría llenar otra entrada de blog solo con esto.

En muchos de estos casos y para que tengáis las manos quietas, si intentas cambiar la configuración, te saltará un error:

En Managed Instance si tienes (y debes) preocuparte de…

A pesar que gran parte de la configuración que históricamente era de Servidor e Instancia ahora se realiza automáticamente, todavía hay muchas cosas de las que tenemos que estar pendientes y configurar, sobretodo a nivel de la propia base de datos.

Instancia

En la configuración de la Instancia hay dos opciones que siempre es recomendable ajustar, o al menos conocerlas por si en algún momento necesitamos modificarlas:

• Optimize for Ad Hoc Workloads, en las propiedades de nuestra instancia, en la pestaña Advanced. Esta opción es recomendable activarla si nuestra base de datos recibe muchas consultas de tipo Ad-Hoc (un solo uso), ya que evitará que se guarde en memoria el plan de ejecución para estas consultas que solo se realizan una vez, con eso conseguiremos que nuestra memoria no se llene de planes de ejecución que no se van a reutilizar. Más información aquí.

• Parallelism, en las propiedades de nuestra instancia, en la pestaña Advanced. Una rápida explicación de paralelismo sería el número máximo de cores que una consulta podrá utilizar, y dentro de esto, las dos opciones a tener en cuenta son Max Degree of Parallelism y Cost Threshold for Parallelism. Más información aquí.
  • Max Degree of Parallelism permite establecer los cores máximos que se podrán utilizar, por defecto 0 (todos). Las Best Practices de algunas aplicaciones como SAP, AX o Sharepoint recomiendan ponerlo a 1, pero este valor dependerá mucho de tu aplicación y sobretodo del tipo de consultas que realices sobre la base de datos.
  • Cost Threshold for Parallelism permite establecer el número de segundos a partir del cual una consulta podrá empezar a usar paralelismo, por defecto es 5 segundos.

Base de datos

A nivel de base de datos es donde más trabajo tendremos que hacer y hay muchas posibilidades de mejorar el rendimiento.

Empezando por los valores de configuración de la propia base de datos:

• Valor de crecimiento, es necesario evitar valores de crecimiento de pocos mb en los archivos de datos y logs, ya que sobretodo a nivel del fichero de Log nos puede generar un gran número de Virtual Log Files, VLFs. Un gran número de VLFs nos pueden ocasionar problemas en muchos aspectos como incrementar muchísimo el tiempo de restauración de una base de datos.
• Compatibility Level, asegurarnos de cambiar (habiendo realizado pruebas antes) el valor de Compatibility Level al más alto para que nuestra base de datos pueda usar las últimas características disponibles en el motor de SQL Server.
• Auto Create y Auto Update Statistics, estas opciones SIEMPRE deberían estar activadas salvo que el fabricante del aplicativo recomiende lo contrario, como es el caso de Sharepoint. Más información de por que hay que activarlas aquí.
• Query Store, por defecto viene activado, pero no está de más que lo verifiquemos porque esta opción nos guarda un histórico de planes de ejecución y estadísticas de nuestras consultas, y esta información es muy valiosa para muchos aspectos.

Automatic Tuning: También desde SQL Server 2017 tenemos disponible esta opción, que, como su propio nombre indica, hará modificaciones automáticas para mejorar el rendimiento de nuestras consultas si detecta que no se esta utilizando el plan de ejecución más óptimo. Más información aquí.

Con la siguiente sentencia lo activaremos sobre la base de datos seleccionada:

ALTER DATABASE current
SET AUTOMATIC_TUNING ( FORCE_LAST_GOOD_PLAN = ON );

Mayor tamaño de fichero, Mayor IO: Un dato MUY IMPORTANTE que tenemos que conocer es que cada fichero de base de datos en Managed Instance se guarda en un disco SSD independiente, y en Azure los IOs máximos dependen del tamaño del disco.

Los discos que se usarán variarán desde el más pequeño de 128Gb (P10) al mayor de 4Tb (P50), la siguiente tabla muestra los IOs y la transferencia de cada uno:

Un ejemplo, si tenemos una base de datos con un fichero de datos de 10Gb entonces estará alojado en un disco P10 con 500 IOs, pero si ampliamos ese fichero a 550Gb entonces cambiará el fichero a un disco P20 con 2300 IOs.

Por lo que, si en algún momento detectamos que nuestra base de datos está teniendo un problema de IOs, con ampliar el tamaño de sus ficheros conseguiremos una mejora de rendimiento considerable.

Esta información y un estudio con test de IO completo lo podéis encontrar en esta entrada de Jovan Popovic, uno de los mayores expertos de Managed Instance en la actualidad.

Planes de Mantenimiento, siempre

Al igual que ocurre en cualquier versión de SQL Server, necesitaremos unos planes de mantenimiento que mantengan a punto nuestra instancia, y si hablamos de planes de mantenimiento, por encima de todos destacan los Planes de Mantenimiento de Ola Hallengren que podéis descargar aquí. En nuestro caso no necesitaremos el plan de backup, pero si serán necesarios los planes de IndexOptimize y de IntegrityCheck.

En la próxima entrada…

Hablaré de los paneles que tenemos en SQL Server Management Studio y Azure Data Studio que nos ayudarán a obtener métricas muy valiosas y que incluso nos detectará mejoras de rendimiento que podemos aplicar en nuestra Managed Instance.

Si tienes  problemas de rendimiento en Managed Instance o en SQL Server, o si estás planeando migrar a Azure, nosotros contamos con la experiencia para ayudarte y asesorarte, contacta con nosotros en info@aleson-itc.com o llámanos al +34 962 681 242