Archivo de la categoría: SQL Server

Shrink todas las bases de datos de un servidor de una manera rapida en SQL Server

SqlServer1En mis maquinas virtuales de desarrollo de SharePoint 2010, muchas veces me encuentro con que, el tamaño de las bases de datos SQL Server de SharePoint se ha disparado y me estoy quedando sin espacio.

Para reducir el tamaño de las bases de datos, normalmente lo que suelo hacer es un shrink (procedimiento almacenado para reducir el tamaño de los archivos de datos y de registro de la base de datos especificada).

Aunque he leído varios posts en los que no se aconseja eliminar esta información en entornos SharePoint, aquí os dejo un articulo interesante de Microsoft sobre el mantenimiento de bases de datos SharePoint 2010: Database maintenance for SharePoint 2010 Products, donde comentan el correcto uso de este comando.

Volviendo a la cuestión que nos atañe… Para poder liberar de una forma cómoda y sencilla, espacio de todas la bases de datos de una instancia de SQL server, has de ejecutar esta sentencia SQL:

declare @db varchar(255)
declare cur cursor for
select name from sys.databases where is_read_only=0 and state=0
  and name not in ('master','model','tempdb','msdb')
open cur
fetch cur into @db
while @@fetch_status=0
begin
  exec SP_dboption @db,'trunc. log on chkpt.','true' 
  DBCC shrinkdatabase (@db)
  fetch next from c into @db
end
close cur
deallocate cur

 

Este script lo que hace es lo siguiente: obtener una lista de todas las bases de datos (exceptuando las del sistema: master, model, tempdb y msdb), posteriormente establece la base de datos en ReadOnly y luego reducir el tamaño del archivo.

El resultado es el siguiente, donde te informa el tamaño inicial y el resultante:

shrink

 

Consultar los logs de ULS de SharePoint 2010 en SQL Server

Es posible que se os haya dado el caso de tener que consultar los logs de SharePoint 2010 conocidos como Unified Logging System (ULS), en entornos formados por grandes granjas de servidores… Este proceso en este caso se convierte en algo tedioso, si no tienes forma de identificar en que servidor físico estas haciendo la petición, para consultar su Correlation ID.

Antes de nada indicar que Microsoft recomienda no acceder directamente a la información de la plataforma, desde la base de datos, sino que debe hacerse a través del modelo de objetos de SharePoint. Este seria el único caso excepcional, donde podemos acceder directamente a través de consultas SQL.

SharePoint 2010, a nivel de granja crea una base de datos llamada WSS_Logging, donde almacena toda la información de la plataforma SharePoint, como por ejemplo: información que envía al visor de eventos de Windows, información de los contadores de rendimiento, inventario de los sitios existentes, los logs de ULS… eso si con un periodo de antigüedad de 14 días, toda información que pase de ese tiempo sera eliminada.

La información de esta base de datos, también es usada para consolidar los datos de Web Analytics a través de los jobs Microsoft SharePoint Foundation Usage Data Import y Microsoft SharePoint Foundation Usage Data Processing.

También es importante remarcar, que la información se vuelca desde la granja a la tabla WSS_Logging, a través de varios timer job que se ejecuta cada varios minutos (este valor es diferente para cada uno de ellos). Aquí tenéis el listado de jobs que vuelca información a esta base de datos (estos datos pueden consultarse en la Administración Central):

El job en concreto, que actualiza la información en el ULS es: Diagnostic Data Provider: Trace Log y se ejecuta por defecto cada 10 minutos y esta es su configuración:

Si, como comentábamos anteriormente, queremos acceder a la misma información que existe en los logs de SharePoint, directamente, deberemos realizar consultas sobre la vista: [dbo].[ULSTraceLog]. Es importante remarcar que debes utilizar las vistas y no las tablas para realizar las consultas.

Los campos de esta vista son: [PartitionId], [RowId], [LogTime], [MachineName], [ProcessID], [ProcessName], [ThreadID], [Area], [Category], [Level], [EventID], [Message], [CorrelationId], [RowCreatedTime]. Estos campos son similares a la informacion que se almacenan en los archivos de ULS.

Como veis existe el campo  [CorrelationId] por el cual vamos a conseguir filtrar los datos, para cotar la información.

De este modo, podrás localizar registros de logs sin tener que buscar físicamente en varios archivos ULS, a través de la granja…

Reducir el tamaño del fichero de log en SQL Server 2005

Hoy me ha tocado realizar tareas de mantenimiento en uno de los servidores de desarrollo, y he visto que gran parte del espacio en disco se lo estaba comiendo uno de los ficheros de una base de datos SQL Server de una aplicación de SharePoint.

Para los que no tengan muy claro, como almacena SQL Server las bases de datos, decir que hay al menos dos ficheros por base de datos. Uno de estos ficheros es donde estarán almacenados los datos de nuestras tablas, vistas y demás objetos (el cual tiene extensión *.mdf)… y el otro es el fichero de transacciones (el cual tiene extensión *.ldf). El fichero de transacciones consiste en una serie de registros de todas las modificaciones de la base de datos y de la transacción que ha realizado cada modificación. En el registro de transacciones figura el inicio de cada transacción. También registra los cambios de los datos y facilita suficiente información para deshacer las modificaciones (si fuera necesario posteriormente) realizadas durante cada transacción.

Como os podeis imaginar, el archivo *.ldf o de transacciones puede ocupar un tamaño considerable, por lo que a veces, nos interesa reducirlo o truncarlo. Si no nos interesa realizar una copia previa de este archivo, lo mas rápido es ejecutar una consulta SQL, para ello, abrimos el analizador de consultas e introducimos esta query:

USE MiBase
CHECKPOINT
EXEC sp_addumpdevice 'disk', 'CopiaMiBase', 'd:LogMiBase.bak'
BACKUP DATABASE MiBase TO CopiaMiBase
BACKUP LOG MiBase WITH TRUNCATE_ONLY
DBCC SHRINKFILE (MiBase_Log, 100)
Hay que sustituir MiBase por el nombre de la base de datos en la que queramos reducir el archivo de transacciones. Existe un paramento que podemos modificar a nuestro gusto, que es el tamaño del archivo *.ldf, actualmente establecido a 100 (en megabytes, expresado como un número entero). Aquí tenéis más información sobre la instruccion DBCC SHRINKFILE y sus parámetros.