Om de prestaties, capaciteit en integriteit van Sharepoint databases te waarborgen is een gedegen maintenance plan van serieus belang. Voordat Service Pack 2 released werd, hadden we een gewelding Whitepaper van Bill Baer http://go.microsoft.com/fwlink/?LinkId=111531&clcid=0x409 welke ons de fijne kneepjes van Sharepoint Database Maintenance bijbracht. Daarnaast hadden we nog het overzicht over de mogelijkheden met Maintenance plans voor SQL op http://support.microsoft.com/kb/932744/. Met de wijzigingen in Service Pack 2 komt hier iets verandering in.
In service pack 2 is er een grote wijziging aangebracht aan de Database Statistics timerjob. Voor SP2 was de enige taak van deze job de query statistics te updaten van de content databases. Na uitrol van SP2 is deze job echter ook verantwoordelijk voor het defragmenteren van de indices (oftewel het herstructureren van de data aangezien de sharepoint contentdatabases gebruik maken van clustered indices). Hiervoor gebruikt Sharepoint volgende stored procedure:
USE [WSS_Content]
GO
/****** Object: StoredProcedure [dbo].[proc_DefragmentIndices] Script Date: 05/08/2009 04:05:36 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER PROCEDURE [dbo].[proc_DefragmentIndices]
AS
BEGIN
SET NOCOUNT ON
DECLARE @objectid int
DECLARE @indexid int
DECLARE @command varchar(8000)
DECLARE @baseCommand varchar(8000)
DECLARE @schemaname sysname
DECLARE @objectname sysname
DECLARE @indexname sysname
DECLARE @currentDdbId int
SELECT @currentDdbId = DB_ID()
PRINT CONVERT(nvarchar, GETDATE(), 126) + ': Starting'
DECLARE @onlineState varchar(10)
DECLARE @edition int
SELECT @edition = CAST(SERVERPROPERTY('EngineEdition') AS int)
IF (@edition <> 3) SET @onlineState = 'OFF) '
ELSE SET @onlineState = 'ON) '
-- Loop over each of the indices
DECLARE indexesToDefrag CURSOR FOR
SELECT
i.object_id,
i.index_id,
i.name
FROM
sys.indexes AS i
INNER JOIN
sys.objects AS o
ON
i.object_id = o.object_id
WHERE
i.index_id > 0 AND
o.type = 'U'
OPEN indexesToDefrag
-- Loop through the partitions.
FETCH NEXT
FROM
indexesToDefrag
INTO
@objectid,
@indexid,
@indexname
WHILE @@FETCH_STATUS = 0
BEGIN
-- Lookup the name of the index
SELECT
@schemaname = s.name
FROM
sys.objects AS o
JOIN
sys.schemas AS s
ON
s.schema_id = o.schema_id
WHERE
o.object_id = @objectid
PRINT CONVERT(nvarchar, GETDATE(), 126) + ': ' + @schemaname + '.' + @indexname + ' is now being rebuilt.'
-- Fragmentation is bad enough that it will be more efficient to rebuild the index
SELECT @baseCommand =
' ALTER INDEX ' +
@indexname +
' ON ' +
@schemaname + '.' + object_name(@objectid) +
' REBUILD WITH (FILLFACTOR = 80, ONLINE = '
-- Use dynamic sql so this compiles in SQL 2000
SELECT @command =
' BEGIN TRY ' +
@baseCommand + @onlineState +
' END TRY ' +
' BEGIN CATCH PRINT CONVERT(nvarchar, GETDATE(), 126) + '': Going offline'' ' +
-- Indices with image-like columns can't be rebuild online, so go offline
@baseCommand + 'OFF) ' +
' END CATCH '
PRINT CONVERT(nvarchar, GETDATE(), 126) + ': Rebuilding'
EXEC (@command)
PRINT CONVERT(nvarchar, GETDATE(), 126) + ': Done'
FETCH NEXT FROM indexesToDefrag INTO @objectid, @indexid, @indexname
END
CLOSE indexesToDefrag
DEALLOCATE indexesToDefrag
RETURN 0
END
Dit betekent echter wel dat deze 'limiet' van 100GB iets belangrijker wordt dan voor SP2, daar je bij het gebruik van deze timer job minder controle hebt over wanneer de defragmentatie wordt uitgevoerd, iets wat dus wel impact heeft op de server farm.
Denk dus na over je aanpak omtrent defragmentatie van databases.
Heb je een grote farm, dan zou ik adviseren maintenance plans te gebruiken voor statistics en defragmentatie. je zult dan via Central Administration de database timerjob moeten disablen. Heb je een kleine farm, adviseer ik de database timerjob te gebruiken. Eventuele maintenance plans die al defragmentatie (reorganize) jobs bevatten, dienen aangepast te worden.