SQL Server 2016 - Configuraciones de ambito de base de datos

SQL Server 2016 trae muchos cambios muy impresionantes entre ellos es el uso de lo que antes eran banderas de comportamiento llamadas trace flag por defecto  en esta ocasión, pero de lo que quiero hablar es el uso de configuraciones de ámbito o locales de bases de datos, un comportamiento similar era obtenido anteriormente por medio de gobierno de recursos.

El gobernador de recursos es una herramienta muy útil pero aun así tiene ciertas limitaciones para el uso día a día, siendo estas el requerimiento de "Control server" como mínimo y la versión enterprise.

Max DOP: Este cambio tiene un impacto pues antes algunas configuraciones como seria el grado de paralelismo, el cual antes era un valor global, a partir de 2016 esta configuración puede ser a nivel base de datos, esto hace que ambientes que tenían diferentes funciones como lo serian aquellos que tienen bases de datos de Sharepoint que requieren configuraciones especiales ya puedan compartir la misma instancia sin afectar su rendimiento.

Legacy Cardinal Estimation: Otro de los cambios son el uso de las banderas como ya se había mencionado, en SQL Server 2014 se trajo un nuevo estimador de cardinalidad que dio muchos dolores de cabeza a varios DBA en su momento, esto erra corregido por medio de las trace flag 2312 y 9481. 

• 2312: Si la base de datos estaba usando una compatibilidad igual o anterior a 110 forzaba los queries a usar el estimador del 2014
• 9481: Si la base de datos estaba usando una compatibilidad 120 forzaba a usar el estimador de cardinalidad del 2012

Optimize for unknown: A esto debemos de añadir unas banderas que han cambiado su función como 4199 que era para cargas masivas solamente y ahora esta activa por defecto..

https://support.microsoft.com/en-us/kb/974006

Parameter Sniffing: Este controlar que por defecto SQL Server, intente predecir que es lo que enviaran a sus procedimientos almacenados y crear planes adecuados, antes podía ser desactivado con una bandera pero este comportamiento ahora es controlado por esta configuración y podemos indicarle que no lo haga, lo cual genera planes con un "optimize for unknow" lo cual genera un comportamiento mas lento pero más predecible.

Cada uno de estos cambios es importantes por si mismo y claramente no remplazan al gobierno de recursos pero son configuraciones rápidas, que no dependerán más allá que del dueño de la base de datos, obvio tiene limitaciones como el control de memoria y IO que puede tener el gobierno de recursos pero son funciones con un gran potencial en el desempeño de nuestras bases de datos.