Oh! sorpresa la base de datos temporal que utiliza para realizar sus operaciones de creación, modificación y eliminación puede creecer hasta llenar por completo el disco donde esta ubicada.
El disco donde estaba almacenada esta base de datos tempDb tenia 2 TB y fueron consumidos en su totalidad, así que mucho cuidado.
La base de datos TempDb en Sql Server 2016 se crean archivos separados por nucleos lógicos en el caso nuestro teniamos 4 núcleos entonces creó 4 archivos separados uno por cada núcleo;un arhivo .MDF y 3 archivos .NDF. Y estos mostraban el tamaño de 500 GB cada uno, como se muestra abajo:
Este servidor es el BackEnd de una Granja de SharePoint 2016. Y el reporte del usuario fue que no podía agregar una bilioteca de imágenes. Al revisar el log de SharePoint se encotró el siguiente error:
02/02/2017 16:49:30.93
w3wp.exe
(0x21AC0)
0x2424C
SharePoint Foundation
Database
880j
High SqlError: 'Could not allocate space for object
'dbo.EventCache'.'EventCache_ListId' in database 'WSS_Content_xxx' because
the 'PRIMARY' filegroup is full. Create disk space by deleting
unneeded files, dropping objects in the filegroup, adding additional files
to the filegroup, or setting autogrowth on for existing files in the
filegroup.' Source: '.Net SqlClient Data Provider' Number:
1105 State: 2 Class: 17 Procedure: 'proc_LogChangeEx' LineNumber: 28 Server:
'SHAREPOINTDB'
1833d19d-e9f5-b035-1066-9145bf5ded4f
Su configuración inicial fue la siguiente:
Crecimiento Inicial Tenia 1024 Mb
AutoCrecimiento
Crecimiento en 64 MB
Limite de Crecimiento No Restringido
Solución
La solución pues tendría que ser reducir el tamaño de la base de datos por medio de un Shrink, pero para ambientes de producción no es recomendado hacerlo en caliente y en horarios laborales. Por ello se tomaron las siguientes medidas:
Procedimiento Efectuado:
1) Solicitar Ventana de Mantenimiento de Emergencía
2) Dentro de la ventana de mantenimiento se efectuó el siguiente procedimiento:
2.1.) Se ejecutaron las siguientes líneas en t-sql con el Management Studio:
use tempdb
GO
DBCC FREEPROCCACHE -- clean cache
DBCC DROPCLEANBUFFERS -- clean buffers
DBCC FREESYSTEMCACHE ('ALL') -- clean system cache
DBCC FREESESSIONCACHE -- clean session cache
DBCC SHRINKDATABASE(tempdb, 99); -- shrink tempdb
Esto liberó 450 Gb el disco que estaba lleno y no permitio reiniciar con seguridad
2.2) Reinicio del Servidor de SQL Server
2.3) Ejecución de los siguientes comandos de t-SQL:
go
USE tempdb;
GO
DBCC SHRINKFILE (tempdev, 64); --libere el espacio del archivo de base de datos y dele un tamaño de 64MB
GO
--2 1 8192 8192 472 472
DBCC SHRINKFILE (temp2, 64); --libere el espacio del archivo de base de datos y dele un tamaño de 64MB
GO
--2 3 8192 8192 184 184
DBCC SHRINKFILE (temp3, 64); --libere el espacio del archivo de base de datos y dele un tamaño de 64MB
GO
--2 4 8192 8192 120 120
DBCC SHRINKFILE (temp4, 64); --libere el espacio del archivo de base de datos y dele un tamaño de 64MB
GO
--2 5 8192 8192 32 32
2.4) Se modificó las propiedades de cada data file para que creciera un máximo de 10 Gb o 10240 Mb.
Con ello se liberó el espacio y se garantizó que no puede llegar a ser mayor a 10 Gb cada archivo de base de datos o ndf file dando un total de 40 GB que estamos es más que suficiente para las operaciones de la granja de SharePoint 2016.
Luego se probó crear la biblioteca y se efectuó la operacíon con éxito sin problemas.
En resumen tenga cuidado cuando se configura SQL Server 2016 de limitar el tamaño de la base de datos tempdb un tamaño que según estime las operaciones que realizará la base de datos pueda manejar, defina un limite máximo para los archivos MDF y LDFs de la base de datos TempDB.
Microsoft también recomienda que tenga un tamaño igual inicial y un incremento igual es decir todas esten configuradas con el mismo tamaño de crecimiento que en este caso es de bloques de 64 MB.
Datos interesantes sobre la tempdb en SQL Server 2016 puede revisar este enlace:
https://blogs.msdn.microsoft.com/psssql/2016/03/17/sql-2016-it-just-runs-faster-automatic-tempdb-configuration/
Hasta la próxima y cuidado con la tempDB.
Juan Manuel Herrera Ocheita
