Configurando SQL Server para SharePoint

En el post de hoy vamos a continuar configurando nuestro SQL Server para alojar bases de datos de SharePoint. Si ayer vimos lo necesario para diseñar correctamente la infraestructura y las peculiaridades de una instalación con este fin hoy vamos a continuar con las configuraciones específicas que tendremos que implementar para lograr el mejor rendimiento posible.

En el menú del día tenemos de plato principal las buenas prácticas de configuración y terminaremos con las particularidades del mantenimiento de este tipo de bases de datos. 

Configuraciones específicas de SQL Server para SharePoint

Como hemos dicho, SharePoint necesita de una serie de configuraciones particulares en nuestros servidores de SQL Server. Si bien no estamos hablando de funcionalidades que existen en exclusiva para esta herramienta, la combinación de estas configuraciones nos permitirá sacar todo el partido posible de nuestras bases de datos.

Configuraciones de disco duro

Dedicamos gran parte del pasado post a este apartado, no es para menos, como os dije SharePoint es una herramienta que hace un uso intensivo de este recurso. Sobre todo lo que ya hablamos quiero añadir que una vez instalado SQL Server, y si tenemos varios tipos distintos de discos para almacenar nuestras bases de datos, usaremos nuestros discos más rápidos para la TempDB y los registros de transacciones de las bases de datos. Seguido por los archivos de las bases de datos de búsqueda.
Para terminar almacenaremos los archivos de datos de las bases de datos de contenido y por último las bases de datos de configuración. A poder ser usaremos discos optimizados para escrituras en la base de datos TempDB y en los logs de transacciones y optimizados para lectura en las bases de datos de búsqueda y contenido. Si nuestro SharePoint está más enfocado a la lectura que a las escrituras priorizaremos los archivos de datos sobre los logs de transacciones.
Recuerda también configurar el tamaño de bytes per cluster a 64kb tal como vimos en las buenas prácticas generales para SQL Server.

Configuración de memoria RAM

A nivel sistema operativo, configuraremos la paginación manualmente con un tamaño fijo de 1,5 veces el tamaño de la memoria RAM que tenga nuestro servidor. Este archivo de paginación estará en un disco dedicado lo más rápido posible.  En SQL Server configuraremos la memoria mínima y la máxima de SQL Server siempre dejando un mínimo de 3 o 4 Gb libres para que el sistema operativo pueda funcionar. Para estos servidores, siempre que tengamos un servidor SQL dedicado configuraremos el mismo valor de memoria mínimo y máximo. 

Para entender esto es necesario saber cómo funciona la asignación de memoria en SQL Server, veámoslo rápidamente. SQL Server gestiona los recursos de nuestra máquina a través de su propio subsistema operativo dedicado. Este SQL SO, además de gestionar las colas de CPU gestiona la memoria RAM. Cuando arrancamos SQL Server irá “cogiendo” memoria a medida que la necesite (hasta el valor máximo que hayamos asignado) y cuando deje de necesitarla se la quedará reservada. Si el sistema operativo tiene falta de memoria SQL “devolverá” la que no esté usando (hasta quedarse en el valor mínimo que hayamos definido). Esto quiere decir que nuestro SQL puede consumir menos RAM del mínimo que le hayamos asignado si hasta ese momento no ha necesitado de esa memoria.

Una vez que ya tenemos claro cómo funciona la gestión de memoria de SQL Server podemos entender lo que necesitamos para nuestro SQL Server para SharePoint. Asignaremos un valor mínimo igual más máximo y será el total de la RAM disponible menos los 3 o 4 Gb que necesita el sistema operativo y lo que estimemos que necesitan otras aplicaciones imprescindibles como las de copia de seguridad.

Otras configuraciones de SQL Server

Para continuar con las configuraciones de nuestra instancia de SQL Server las buenas prácticas hablan de activar la opción de comprimir backups. Como en este blog nos gusta profundizar en los temas vamos a entrar en detalle en este punto. Comprimir backup tiene un mayor consumo de recursos y un peor rendimiento a la hora de hacer y restaurar las copias de seguridad. Hablamos obviamente de recursos de CPU y RAM. El problema viene con el resto de recursos, disco y red. Como hablamos de bases de datos pesadas, el extra de coste en CPU y RAM se ve compensado por la reducción de disco y de red por lo que en este caso es una buena práctica recomendada.

Otra de las recomendaciones que nos da Microsoft para los servidores SQL Server para Sharepoint es configurar el Fill Factor al 80%. No vamos a entrar en detalle sobre esto ya que ya hemos hablado de ello en otro post.

Cerramos el apartado sobre las configuraciones hablando de la configuración de CPU, en este caso estableceremos el nivel de paralelismo a 1. El nivel de paralelismo indica cuántos núcleos de CPU usarán nuestras consultas, un valor elevado es ideal para servidores con pocas consultas pero pesadas mientras que en servidores con multitud de consultas un valor bajo nos ayudará a tener más consultas ejecutándose simultáneamente. Dado el alto volumen de transacciones simultáneas que va a generar SharePoint en nuestro SQL Server un valor distinto de 1 perjudicará enormemente el rendimiento. 

Configuraciones de bases de datos para SharePoint

Para nuestras bases de datos debemos asegurarnos de que no esté habilitada la opción AutoShink y que no haya ningún trabajo programado que reduzca los ficheros de bases de datos. Aunque esta es una recomendación para la mayoría de bases de datos, en el caso de SharePoint se suele decir que los shrink quedan reservados a ocasiones especiales cuando se haya borrado más del 50% de los datos por parte de un administrador del sitio y tengamos claro que ese espacio no se va a volver a necesitar.

De la misma manera deshabilitaremos la creación y la actualización automática de estadísticas ya que SharePoint se encargará automáticamente de su creación. El tema de las actualizaciones lo vamos a ver luego, cuando hablemos del mantenimiento.

Configuraciones de los ficheros de base de datos de SharePoint

Continuamos con los ficheros de base de datos y como no podía ser de otra manera también tienen configuraciones específicas. En este caso relativas a la distribución y crecimiento.  En una situación ideal, los administradores de SharePoint serán capaces de proporcionarnos el crecimiento esperado de las bases de datos en un año, en estos casos dimensionamos los ficheros en ese tamaño estimado más un 20% de margen. Sin embargo, la realidad es distinta, normalmente no sabremos la tasa de crecimiento anual. En estos casos dimensionamos nuestros ficheros al máximo (o cerca del máximo) del tamaño que hayamos estimado que vayan a crecer  en total(recuerda que en el anterior post explicamos la fórmula para calcular el crecimiento de las bases de datos).
Por lo general, Microsoft no recomienda bases de datos de más de 200Gb para SharePoint, en caso de necesitar más espacio deberá estar dividido en colecciones en distintas bases de datos. SharePoint tiene su propia herramienta para poder mover colecciones entre bases de datos. Tener los ficheros dimensionados a su máximo tamaño nos ahorrará el tiempo que dedica el motor de base de datos a ampliar el tamaño de estos cuando no tiene sitio para alojar información nueva y optimiza las escrituras en SharePoint. 

Crecimiento de los ficheros de base de datos de SharePoint

Sin embargo, aunque tengamos los ficheros dimensionados es importante configurarlos con crecimiento automático para que, en caso de ser necesario, puedan crecer. Configuraremos un crecimiento automático elevado, para evitar que cada transacción nueva tenga que dedicar tiempo a esta tarea. No tengáis miedo a los crecimientos en bloques de varios Gb, recordad que nuestros SharePoint van a almacenar documentos de varios cientos de Mb en ocasiones. Estableceremos crecimientos de 512 Mb para las bases de datos pequeñas y de 5 Gb para las bases de datos de más de 50 Gb. Usar porcentajes de crecimiento no es una práctica recomendada.

Por último, para los logs de transacciones, configuraremos un tamaño de un 25% o 30% del tamaño total de los ficheros de datos.

Distribución de los ficheros de base de datos de SharePoint

Configuraremos nuestras bases de datos de contenido con varios ficheros, a poder ser en varios discos (y varios LUNs) para ganar rendimiento de E/S. En estos casos usaremos la misma regla que usamos normalmente para la TempDB, crearemos un fichero por cada núcleo de nuestro procesador con un máximo de 8 ficheros. Es importante que todos los ficheros tengan el mismo tamaño inicial, pues crecerán a la vez y esto mejora el rendimiento. Si nuestro SQL Server es anterior a 2016 no hará crecer los ficheros a la vez por defecto y deberemos indicarlo con la traza -T1117 en el arranque.

Base de datos TempDB

Hablando de la TempDB, aprovisionaremos un tamaño inicial igual al 25% o 30% del total del tamaño de datos que hayamos estimado que vamos a tener. Repartiremos ese tamaño total entre tantos ficheros como CPUs tengamos con un máximo de 8. Todos los ficheros tendrán el mismo tamaño inicial.

Base de datos Model

SharePoint creará las bases de datos que necesite, por lo que es importante trasladar todas las anteriores consideraciones a nuestra base de datos model a fin de que se puedan aplicar automáticamente en todas las nuevas bases de datos.

Mantenimiento de bases de datos de SharePoint

Como en cualquier otro servidor SQL Server se hace imprescindible configurar un plan de copias de seguridad y un chequeo de integridad de las bases de datos periódicamente. 

En cuanto al mantenimiento de índices y estadísticas tenemos que conocer la versión de SharePoint que se está ejecutando. En SharePoint 2012 o inferior este gestionará el plan de mantenimiento de índices y estadísticas por lo que no deberemos nosotros duplicar ese trabajo. Para SharePoint 2013 o superior si que debemos configurar nuestros planes de mantenimiento con normalidad. Como ya sabéis, en estos casos yo os recomiendo las herramientas de Ola Hallengren.

Conclusión

Hoy hemos aprendido a configurar nuestros servidores SQL Server para alojar las bases de datos de SharePoint. Es importante repetir estos pasos en todos los servidores de la granja de SharePoint para sacar todo el partido de esta aplicación. Tanto si vais a desplegar un nuevo servidor SharePoint como si ya lo tenéis, aplicad estos consejos y los del post de instalación y veréis como mejora el rendimiento. Yo lo hice en un cliente y os aseguro que el volumen de incidencias por lentitud se redujo drásticamente. 

Y ya no me enrollo más, recuerda que puedes dejarme tus comentarios o preguntas al final del artículo, en Twitter o por mail. Hasta la próxima.