Crecimiento excesivos de las archivos logs de SQL en SharePoint

Es un problema típico en el mantenimiento de un portal de una instalación típica de SharePoint que no se ha atendido adecuadamente. Y esto ocurre cuando se realiza una plan de mantenimiento en SQL-Server que incluye la realización de copias de seguridad de la base de datos de contenido con un alta periodicidad.

No que esto este mal, de ninguna manera pero si podemos causar el crecimiento excesivo de los archivos logs de las bases de datos de SharePoint por desconocimiento y por falta de atención en el mantenimiento del servidor de base de datos.

En este artículo resumiré el porqué de este crecimiento excesivo, las posibles soluciones y los consejos prácticos que descubrí en la investigación echa en la red que se fundamenta en los artículos escritos por el gurú de SQL Server Paul S. Randal .

Artículos en que se baso la investigación:

http://technet.microsoft.com/en-us/magazine/2009.02.logging.aspx

http://technet.microsoft.com/en-us/magazine/2008.08.database.aspx?pr=blog

A qué se debe del crecimiento excesivo de los logs de las bases de datos de SharePoint

El modelo de recuperación típico en una instalación de SharePoint es Full Recovery este no es afectado sino hasta el momento que se realiza un Backup completo. Entonces sumemos los siguientes factores: Full Recovery y un plan de mantenimiento para la base de datos que realiza un backup completo diario de una base de datos de contenido de SharePoint WSS_Content, de unos 11 Gigas, en poco tiempo (aprox. 3 semanas) tendremos un archivo ldf o log de 41 Gigas y si el espacio disponible de nuestro disco es de tan solo 50 gigas, prácticamente ya se lleno y tendremos como resultado un colapso en el funcionamiento de SharePoint.

Que hacer?

Realice un Shrink de emergencia. Aunque no es la solución ideal la emergencia lo amerita. Vea el procedimiento adecuado y otros temas relacionados al mantenimiento de las bases de datos de SharePoint en el siguiente documento de las mejores prácticas para ello en: http://office.microsoft.com/download/afile.aspx?AssetID=AM102632301033.

Que es lo que debería de hacer?

Realizar el backup de log también para reducir el tamaño del archivo ldf de la base de datos o cambiar el modelo de recuperación de la base de datos a simple. Que desventajas tiene este cambio: pues que no podrá restaurar hasta el ultimo instante cuando se corrompió la base de datos, sino hasta el ultimo backup completo realizado. Pero enfrentémoslo, no podrá recuperarlo si de todos modos solo hace backup completos y no utiliza backups diferenciales cada cierto tiempo mas corto que el del completo (cada cierta cantidad de horas). Para ello hay otras recomendaciones que podrá encontrar al rededor de las referencias mencionadas y que están fueras del alcance de este artículo.

Consejos Prácticos

Dentro de las investigaciones realizadas encontré los siguientes consejo útiles que debemos de tomar en cuenta. A continuación los detallo:

En los archivos ldf pueden tener un impacto muy significativo en el rendimiento de la base de datos, especialmente si la opción auto-growth es configurada para incrementar su tamaño automáticamente solamente por montos muy pequeños cada vez que sea necesario. Lo mejor es definir un tamaño estimado de una sola vez para que no ocurra esto en cada momento en vez del cómodo pero deficiente porcentaje.

Finalmente, deberá cuidarse que la opción Auto Shrink no este habilitada de ninguna forma. Esto puedo reducir el tamaño del archivo mdf (data) o ldf(log), pero es muy dañino, ya que es un proceso pesado de recursos que causan montos masivos de archivos fragmentados que hacen pesada la búsqueda de la información internamente.

Un plan de mantenimiento regular que incluye la ejecución del comando shrink en la base de datos es igual de malo. Si descubre que la base de datos crece luego de la ejecución del plan mantenimiento esto se debe a que la base de datos necesita el espacio en el cual esta ejecutándose. Entonces que hacer?.. Nuevamente como ya dijimos haga un backup del log o cambie el modelo de recuperación de la base de datos a simple.

Ultima recomendación lea los artículos de referencia, vea el video que hay en uno de ellos y aplique su criterio para definir la mejor estrategia que tomará para minimizar o controlar este problema.

Hasta la próxima amigos!,

Manolo Herrera