Résoudre les problèmes de ralentissement des performances de la console Data Protection Manager

Ce guide vous aide à diagnostiquer et résoudre les problèmes de performances avec la console d’administration dans System Center 2016 Data Protection Manager (DPM 2016) et System Center 2012 Data Protection Manager (DPM 2012 ou DPM 2012 R2).

Version du produit d’origine : System Center 2016 Data Protection Manager, System Center 2012 Data Protection Manager, System Center 2012 R2 Data Protection Manager

Ce guide se concentre sur les problèmes les plus courants liés à la base de données. Si des problèmes généraux de performances sont observés sur l’ensemble du serveur, le serveur peut être surutilisée. Une trace de moniteur de performances est un bon point de départ si vous suspectez des problèmes de performances à l’échelle du serveur. Bien que l’évaluation des performances du serveur soit un élément idéal pour les experts, nous avons des instructions générales pour l’analyse des performances du serveur à l’adresse Use PerfMon pour diagnostiquer les problèmes courants de performances du serveur.

Dans ce guide, nous allons examiner uniquement les problèmes de performances limités à la console DPM avec l’hypothèse que le reste du serveur fonctionne normalement.

Avant de commencer la résolution des problèmes, vérifiez que vous disposez du package cumulatif de mise à jour le plus récent pour System Center Data Protection Manager installé. Plusieurs problèmes de performances connus ont été résolus dans ces packages cumulatifs. Pour obtenir la dernière version, consultez System Center - Versions de build de Data Protection Manager.

Vérifiez si la base de données DPM est gonflée

Si la base de données DPM est gonflée (supérieure à ce qu’elle doit être) pour une raison quelconque, elle peut ralentir les requêtes retournant des données et également provoquer d’autres problèmes tels que le remplissage du lecteur C : sur le serveur DPM avec les fichiers de données de base de données.

Pour vérifier la taille de DPMDB, cliquez avec le bouton droit sur la base de données et sélectionnez Propriétés :

Recherchez la taille dans les propriétés :

Si la base de données est volumineuse, nous devons identifier les tables responsables. Grande peut être assez subjective, car certaines configurations telles que la protection des batteries de serveurs SharePoint volumineuses entraînent naturellement la croissance de la base de données. Toutefois, s’il provoque des problèmes liés à l’espace disque ou à d’autres problèmes de performances, exécutez le rapport Utilisation des disques par top table sur la base de données DPMDB.

En fonction du rapport, examinez les tables les plus volumineuses. Voici quelques-unes des tables qui sont généralement considérées comme volumineuses :

• Tbl_RM_SharePointRecoverableObject
• Tbl_ARM_DirAndFile et/ou Tbl_ARM_Path
• Tbl_TE_TaskTrail

Si les tailles de base de données et de table apparaissent normales, vérifiez la taille et la fragmentation de l’index de base de données.

La Tbl_RM_SharePointRecoverableObject table est grande

Ce tableau peut devenir volumineux lorsque de grandes batteries de serveurs SharePoint sont protégées (telles que des batteries de serveurs avec des millions d’éléments) ou plusieurs batteries de serveurs sont protégées. La formule suivante montre approximativement la taille de DPMDB lors de la protection d’une grande batterie de serveurs SharePoint :

((Number of items in the farm in millions) x 3) + ((number of content DBs x Number of SQL Servers in the farm x 30) / 1024) = size of DPMDB (GB)

Cette formule considère uniquement la croissance de la base de données liée à la batterie de serveurs SharePoint. La taille réelle peut être plus grande. Dans ce scénario, il n’y a pas beaucoup à faire pour réduire l’espace disque utilisé. Toutefois, vous pouvez inspecter la taille et la fragmentation de l’index de base de données si les performances sont affectées.

Vérifier la taille et la fragmentation de l’index de base de données

Les index volumineux ou hautement fragmentés peuvent entraîner des problèmes de performances significatifs pour les requêtes SQL en cours d’exécution et prendre plus d’espace disque que nécessaire. Pour vérifier la fragmentation, exécutez la requête SQL suivante qui retourne tous les index avec une fragmentation supérieure à 20 % :

SELECT OBJECT_NAME(i.OBJECT_ID) AS TableName,

i.name AS IndexName,

indexstats.avg_fragmentation_in_percent

FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'DETAILED') indexstats

INNER JOIN sys.indexes i ON i.OBJECT_ID = indexstats.OBJECT_ID

AND i.index_id = indexstats.index_id

WHERE indexstats.avg_fragmentation_in_percent > 20

order by TableName

S’il existe un index volumineux pour une ou plusieurs tables, il peut généralement être résolu en régénéré l’index.

Exécutez la requête SQL suivante pour reconstruire un index sur une table particulière :

ALTER INDEX ALL ON <table_name>

rebuild

go

S’il existe de nombreuses tables fragmentées, exécutez la requête suivante pour reconstruire chaque index sur une base de données :

DECLARE @TableName VARCHAR(255)

DECLARE @sql NVARCHAR(500)

DECLARE @fillfactor INT

SET @fillfactor = 80

DECLARE TableCursor CURSOR FOR

SELECT OBJECT_SCHEMA_NAME([object_id])+'.'+name AS TableName

FROM sys.tables

OPEN TableCursor

FETCH NEXT FROM TableCursor INTO @TableName

WHILE @@FETCH_STATUS = 0

BEGIN

SET @sql = 'ALTER INDEX ALL ON ' + @TableName + ' rebuild'

EXEC (@sql)

FETCH NEXT FROM TableCursor INTO @TableName

END

CLOSE TableCursor

DEALLOCATE TableCursor

GO

L’exécution de la requête ne doit pas affecter la capacité de DPM à s’exécuter comme d’habitude. Toutefois, DPM peut s’exécuter un peu plus lent lors de la reconstruction de l’index.

Pour plus d’informations sur la reconstruction d’index dans DPMDB, consultez Améliorer la recherche d’objets récupérableS DPM.

Si la création du catalogue SharePoint prend beaucoup de temps, il est recommandé de reconstruire les index pour les tables et tbl_RM_RecoverySource les tbl_RM_SharePointRecoverableObject tables.

Les Tbl_ARM_DirAndFile tables et/ou Tbl_ARM_Path les tables sont volumineuses

Les paramètres de taille du catalogue de bandes peuvent entraîner la taille de ces tables très volumineuses. Pour réduire la taille de ces tables, modifiez les valeurs de rétention du catalogue de bandes pour réduire les données stockées dans DPMDB.

Le paramètre par défaut consiste à supprimer les entrées à mesure que les bandes expirent. Si des bandes sont conservées pendant plusieurs années, cela peut entraîner une grande quantité de données conservées dans la base de données. Dans ce cas, remplacez les paramètres par le catalogue Prune pour les bandes antérieures à <une courte période de temps>. Par exemple, définissez-le sur 4 semaines.

La mise à jour de ce paramètre ne supprime pas les données sur bande. Les bandes antérieures à la valeur spécifiée doivent être réécrites pour restaurer des données à partir de celles-ci. Veillez à vous conformer aux stratégies de rétention des données de votre organisation avant d’apporter des modifications.

La Tbl_TE_TaskTrail table est grande

Si cette table est de plus en plus volumineuse, les travaux de nuit à nettoyer la base de données peuvent échouer, car le garbage collection doit nettoyer les données antérieures à 33 jours dans la table de la piste des tâches.

Pour vérifier si le garbage collection fonctionne correctement, exécutez la requête SQL suivante :

select * from tbl_TE_TaskTrail tt where datediff (day, tt.stoppeddatetime, getutcdate()) > 33

Si le résultat est 0, le garbage collection fonctionne correctement. Sinon, vous pouvez utiliser le script suivant pour nettoyer manuellement les tables.

Important

Sauvegardez la base de données avant d’exécuter un script sur la base de données.

------------------------- start --------------------------
USE [DPMDB_MUKESH]

GO

select * into dbo.tbl_TE_TaskTrail1 from tbl_TE_TaskTrail where IsGCed = '0'

IF EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id = OBJECT_ID(N'[dbo].[fk_TE_TaskTrail__JM_JobTrail]') AND parent_object_id = OBJECT_ID(N'[dbo].[tbl_TE_TaskTrail]'))

ALTER TABLE [dbo].[tbl_TE_TaskTrail] DROP CONSTRAINT [fk_TE_TaskTrail__JM_JobTrail]

GO

IF EXISTS (SELECT * FROM dbo.sysobjects WHERE id = OBJECT_ID(N'[DF_tbl_TE_TaskTrail_IsGCed]') AND type = 'D')

BEGIN

ALTER TABLE [dbo].[tbl_TE_TaskTrail] DROP CONSTRAINT [DF_tbl_TE_TaskTrail_IsGCed]

END

GO

USE [DPMDB_MUKESH]

GO

alter table dbo.tbl_AM_AgentDeploymentTrail DROP CONSTRAINT fk__AM_AgentDeploymentTrail__TE_TaskTrail__TaskID

alter table dbo.tbl_ARM_TaskTrail DROP CONSTRAINT fk__ARM_TaskTrail__TE_TaskTrail__TaskId

alter table dbo.tbl_CM_InquiryResult DROP CONSTRAINT fk__CM_InquiryResult__TE_Task__TaskID

alter table dbo.tbl_MM_MediaRequiredAlert DROP CONSTRAINT fk__MM_MediaRequiredAlert__TE_TaskTrail

alter table dbo.tbl_MM_Task DROP CONSTRAINT FK_tbl_MM_Task_tbl_TE_TaskTrail

alter table dbo.tbl_MM_TaskTrail DROP CONSTRAINT fk__MM_TaskTrail__TE_TaskTrail__TaskId

alter table dbo.tbl_PRM_CloudRecoveryPointTrail DROP CONSTRAINT fk_PRM_CloudRecoveryPointTrail

alter table dbo.tbl_PRM_ReferencedTaskTrail DROP CONSTRAINT fk__PRM_ReferentialTask_TaskTrail_TaskId

alter table dbo.tbl_RM_CandidateDatasetsForSCAssociation DROP CONSTRAINT fk_RM_CandidateDatasetsForSCAssociation_RM_TaskTrail

alter table dbo.tbl_RM_RecoveryTrail DROP CONSTRAINT fk__RM_RecoveryTrail__TE_TaskTrail__TaskId

alter table dbo.tbl_RM_ReplicaTrail DROP CONSTRAINT fk_RM_ReplicaTrail__TE_Task

alter table dbo.tbl_RM_ShadowCopyTrail DROP CONSTRAINT fk_RM_ShadowCopyTrail__TE_Task

alter table dbo.tbl_TE_TaskError DROP CONSTRAINT FK_tbl_TE_TaskError_tbl_TE_TaskTrail

/****** Object: Table [dbo].[tbl_TE_TaskTrail] Script Date: 07/18/2011 00:25:30 ******/
IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[tbl_TE_TaskTrail]') AND type in (N'U'))

DROP TABLE [dbo].[tbl_TE_TaskTrail]

GO

USE [DPMDB_MUKESH]

GO


/****** Object: Table [dbo].[tbl_TE_TaskTrail] Script Date: 07/18/2011 00:25:30 ******/

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

CREATE TABLE [dbo].[tbl_TE_TaskTrail](

[TaskID] [dbo].[GUID] NOT NULL,

[TaskDefinitionID] [dbo].[GUID] NOT NULL,

[JobID] [dbo].[GUID] NOT NULL,

[VerbID] [dbo].[GUID] NOT NULL,

[ExecutionState] [smallint] NOT NULL,

[ErrorCode] [int] NOT NULL,

[ErrorDetailsXml] [ntext] NOT NULL,

[LastStateName] [nvarchar](128) NULL,

[CreatedDateTime] [datetime] NOT NULL,

[StartedDateTime] [datetime] NULL,

[StoppedDateTime] [datetime] NULL,

[TaskXml] [ntext] NOT NULL,

[ErrorStateName] [nvarchar](128) NULL,

[IsGCed] [bit] NOT NULL,

CONSTRAINT [pk_TE_TaskTrail] PRIMARY KEY NONCLUSTERED

(

[TaskID] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

insert into tbl_TE_TaskTrail select * from tbl_te_tasktrail1

ALTER TABLE [dbo].[tbl_TE_TaskTrail] WITH CHECK ADD CONSTRAINT [fk_TE_TaskTrail__JM_JobTrail] FOREIGN KEY([JobID])
REFERENCES [dbo].[tbl_JM_JobTrail] ([JobId])

GO

ALTER TABLE [dbo].[tbl_TE_TaskTrail] CHECK CONSTRAINT [fk_TE_TaskTrail__JM_JobTrail]

GO

ALTER TABLE [dbo].[tbl_TE_TaskTrail] ADD CONSTRAINT [DF_tbl_TE_TaskTrail_IsGCed] DEFAULT ((0)) FOR [IsGCed]

GO

alter table dbo.tbl_AM_AgentDeploymentTrail ADD CONSTRAINT fk__AM_AgentDeploymentTrail__TE_TaskTrail__TaskID foreign key (taskid) references tbl_te_tasktrail (taskid)

alter table dbo.tbl_ARM_TaskTrail ADD CONSTRAINT fk__ARM_TaskTrail__TE_TaskTrail__TaskId foreign key (taskid) references tbl_te_tasktrail (taskid)

alter table dbo.tbl_CM_InquiryResult ADD CONSTRAINT fk__CM_InquiryResult__TE_Task__TaskID foreign key (taskid) references tbl_te_tasktrail (taskid)

alter table dbo.tbl_MM_MediaRequiredAlert ADD CONSTRAINT fk__MM_MediaRequiredAlert__TE_TaskTrail foreign key (taskid) references tbl_te_tasktrail (taskid)

alter table dbo.tbl_MM_Task ADD CONSTRAINT FK_tbl_MM_Task_tbl_TE_TaskTrail foreign key (taskid) references tbl_te_tasktrail (taskid)

alter table dbo.tbl_MM_TaskTrail ADD CONSTRAINT fk__MM_TaskTrail__TE_TaskTrail__TaskId foreign key (taskid) references tbl_te_tasktrail (taskid)

alter table dbo.tbl_PRM_CloudRecoveryPointTrail ADD CONSTRAINT fk_PRM_CloudRecoveryPointTrail foreign key (taskid) references tbl_te_tasktrail (taskid)

alter table dbo.tbl_PRM_ReferencedTaskTrail ADD CONSTRAINT fk__PRM_ReferentialTask_TaskTrail_TaskId foreign key (taskid) references tbl_te_tasktrail (taskid)

alter table dbo.tbl_RM_CandidateDatasetsForSCAssociation ADD CONSTRAINT fk_RM_CandidateDatasetsForSCAssociation_RM_TaskTrail foreign key (taskid) references tbl_te_tasktrail (taskid)

alter table dbo.tbl_RM_RecoveryTrail ADD CONSTRAINT fk__RM_RecoveryTrail__TE_TaskTrail__TaskId foreign key (taskid) references tbl_te_tasktrail (taskid)

alter table dbo.tbl_RM_ReplicaTrail ADD CONSTRAINT fk_RM_ReplicaTrail__TE_Task foreign key (taskid) references tbl_te_tasktrail (taskid)

alter table dbo.tbl_RM_ShadowCopyTrail ADD CONSTRAINT fk_RM_ShadowCopyTrail__TE_Task foreign key (taskid) references tbl_te_tasktrail (taskid)

alter table dbo.tbl_TE_TaskError ADD CONSTRAINT FK_tbl_TE_TaskError_tbl_TE_TaskTrail foreign key (taskid) references tbl_te_tasktrail (taskid)

DROP TABLE [dbo].[tbl_TE_TaskTrail1]

GO

Tempdb est en train d’être gonflé

Cela n’est pas aussi courant que le ballonnement de DPMDB, mais il peut entraîner des problèmes liés aux performances.

Pour plus d’informations sur tempdb, consultez la base de données tempdb.

Lorsque vous avez une requête qui fonctionne avec une grande quantité de données, tempdb augmente. Toutefois, si tempdb augmente de plusieurs Go, il est généralement dû à une transaction longue. Cela peut empêcher le nettoyage du journal des transactions et le fait continuer à croître jusqu’à ce que la transaction se termine, ou indéfiniment si la transaction ne se termine jamais.

Si d’autres bases de données sont colocalisées sur la même instance SQL Server, cela peut entraîner un problème avec tempdb et affecter les performances de la console DPM.

Pour vérifier s’il s’agit d’un problème avec tempdb, ouvrez les propriétés tempdb dans SQL Server Management Studio :

Si la taille de tempdb est en Go, il peut y avoir un problème. Vous pouvez également voir s’il existe un espace disponible dans tempdb. Si c’est le cas, il est peu probable que ce qui a provoqué la croissance se produise actuellement.

Note

Il est impossible d’activer AutoShrink avec tempdb. Si AutoGrow est activé, une fois que tempdb augmente à une grande taille, elle ne sera pas renvoyée en taille. Pour plus d’informations sur AutoShrink et AutoGrow, consultez Considérations relatives aux paramètres « autogrow » et « autoshrink » dans SQL Server.

Il existe un espace libre disponible dans tempdb

À partir de SQL Server Management Studio, essayez de réduire la taille de tempdb :

Si la taille ne diminue pas autant que prévu, vérifiez la taille initiale :

S’il est défini sur une valeur très importante, supprimez-le à 8 Mo et essayez de réduire à nouveau tempdb. Le redémarrage de l’instance SQL Server réinitialise également la taille de tempdb à sa taille initiale.

Il n’y a pas d’espace libre dans tempdb et la taille augmente toujours

Dans ce cas, il est probable que la requête problématique soit toujours en cours d’exécution. S’il provoque un problème urgent, tel que la consommation de l’espace disque disponible, redémarrez l’instance SQL Server. Toutefois, ce soulagement temporaire rend plus difficile l’identification de la cause du problème.

Si le problème est dû à une requête longue, la requête suivante affiche les transactions en cours d’exécution les plus longues :

SELECT transaction_id, session_id, elapsed_time_seconds FROM sys.dm_tran_active_snapshot_database_transactions ORDER BY elapsed_time_seconds DESC;

Voici un exemple de sortie :

Utilisé avec une trace SQL Server Profiler, vous devez être en mesure de découvrir ce qui se passe dans la session en filtrant ce session_idqui suit :

Vous pouvez trouver la base de données sur laquelle la requête s’exécute et afficher le contenu de la requête dans le volet d’informations. Vérifiez si la base de données est DPMDB. Si ce n’est pas le cas, il s’agit d’une autre application qui provoque le problème et vous devez résoudre ce problème.

Si la requête s’exécute sur DPMDB, vérifiez ce que fait la requête. Si elle appelle une procédure stockée, examinez plus en plus la procédure stockée. Pour ce faire, ouvrez SQL Server Management Studio et recherchez la procédure sous Procédures stockées programmabilité>DPMDB>. Cliquez avec le bouton droit sur la procédure stockée pour afficher plus de détails. Le fait de cliquer sur Modifier vous permet de voir la requête réelle. Examinez les tables qui sélectionnent (ou mettent à jour) pour vérifier s’ils rencontrent des problèmes.

Bien qu’il dépasse le cadre de ce guide pour résoudre des problèmes complexes de table et de requête, cela doit aider à identifier l’emplacement où le problème peut résider. Pour plus d’informations, consultez votre expert SQL Server local ou recherchez sur le forum de support DPM.

Important

Avant d’apporter des modifications, veillez à sauvegarder DPMDB.