BI experience

N’ayant pas de serveurs surdimensionnés à ma disposition, le moindre gigaoctet est précieux.
En monitorant les serveurs j’ai pu constater que la table « Segment » de la base « Reportservertempdb » avait pris un volume de plus de 50Go.

En creusant le sujet, j’ai pu lire sur les forums que cette taille qui augmente pouvait avoir 4 causes:
- Cause 1 : le nombre de snapshot stockés par rapport
- Cause 2 : des rapports qui mettent plus de 10 minutes à s’exécuter
- Cause 3 : la non exécution de la procédure de clean up toutes les 10 minutes.
- Cause 4 : une base qui existe depuis longtemps qui n’a jamais été cleanée

- Solution 1 :
Etape 1 : Aller sur le « report manager », allez dans « Site Settings », et cocher « Limit the copies of report history to : 10  » au lieu du paramètre par défaut.
Etape 2 :Ensuite faire du ménage sur votre plateforme de rapport s’il y en a besoin en supprimant des snapshots non utilisés.

- Solution 2 :
Revoir ces rapports qui prennent trop de temps. Aller sur la base « Reportservertempdb » et exécuter la requête suivante pour les identifier :
 »
select Name, exe.UserName, exe.TimeStart, exe.TimeEnd, DATEDIFF(second,exe.TimeStart, exe.TimeEnd) as DureeEnSeconde
from [ReportServer].[dbo].[ExecutionLogStorage] exe,
[ReportServer].[dbo].[Catalog] cat
where cat.ItemID = exe.ReportID
ORDER BY DATEDIFF(second,exe.TimeStart, exe.TimeEnd) desc »

- Solution 3 :
Aller dans le fichier de Log de votre instance SSRS et regarder s’il y a un message d’erreur concernant la tâche CleanBatch

- Solution 4 :
Possibilité 1 : Vous pouvez choisi cette première possibilité peu extrême et faire ces étapes :
Etape 1 : éteindre le service report serveur
Etape 2 : exécuter un TRUNCATE des tables
Etape 3 : faire un shrink des fichiers de base de données
Etape 4 : redémarrer le service report serveur

Possibilité 2 : ou exécuter ce script pour un nettoyage en douceur :
 »
begin transaction

declare @cleanedSnapshots table (SnapshotDataId uniqueidentifier) ;
declare @cleanedChunks table (ChunkId uniqueidentifier) ;
declare @cleanedSegments table (ChunkId uniqueidentifier, SegmentId uniqueidentifier) ;
declare @deleteCount int ;

insert into @cleanedSnapshots
select distinct SnapshotDataId
from SegmentedChunk
where SnapshotDataId not in (select SnapshotDataID from SnapshotData)

– clean up chunks
set @deleteCount = 1 ;
while (@deleteCount > 0)
begin
delete top(20) SC
output deleted.ChunkId into @cleanedChunks(ChunkId)
from SegmentedChunk SC with (readpast)
join @cleanedSnapshots cs on SC.SnapshotDataId = cs.SnapshotDataId ;
set @deleteCount = @@ROWCOUNT ;
end ;

– clean up unused mappings
set @deleteCount = 1 ;
while (@deleteCount > 0)
begin
delete top(20) CSM
output deleted.ChunkId, deleted.SegmentId into @cleanedSegments (ChunkId, SegmentId)
from ChunkSegmentMapping CSM with (readpast)
join @cleanedChunks cc ON CSM.ChunkId = cc.ChunkId
where not exists (
select 1 from SegmentedChunk SC
where SC.ChunkId = cc.ChunkId )
and not exists (
select 1 from [ReportServerTempDB].dbo.SegmentedChunk TSC
where TSC.ChunkId = cc.ChunkId ) ;
set @deleteCount = @@ROWCOUNT ;
end ;

– clean up segments
set @deleteCount = 1
while (@deleteCount > 0)
begin
delete top(20) S
from Segment S with (readpast)
join @cleanedSegments cs on S.SegmentId = cs.SegmentId
where not exists (
select 1 from ChunkSegmentMapping csm
where csm.SegmentId = cs.SegmentId ) ;
set @deleteCount = @@ROWCOUNT ;
end

commit
 »

Possibilité 3 :ou encore exécuter :
DBCC CLEANTABLE (ReportServerTempDB,’dbo.Segment’, 0)
WITH NO_INFOMSGS;

Et vous? Avez vous déjà rencontré ce problème?