Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server)
S’APPLIQUE À :
2013 2016 2019 Édition d’abonnement 
SharePoint dans Microsoft 365
Les informations fournies sur la planification de la capacité contiennent des indications pour vous aider à planifier et à configurer le niveau de stockage et de base de données SQL Server dans un environnement SharePoint Server. Elles s'appuient sur des tests effectués par Microsoft sur des propriétés activées. Les résultats obtenus peuvent toutefois varier en fonction de l'équipement utilisé et des fonctionnalités mises en place pour vos sites.
En savoir plus sur la gestion des limites de stockage de site pour SharePoint dans Microsoft 365.
Bien que les tests n’aient pas été exécutés sur SQL Server 2014 (SP1), SQL Server 2016, SQL Server 2017 RTM ou SQL Server 2019, vous pouvez utiliser ces résultats de test comme guide pour vous aider à planifier et configurer le niveau de stockage et de base de données SQL Server dans les environnements SharePoint Server Édition d’abonnement, 2019 ou 2016. Pour savoir comment configurer et régler SQL Server 2012, reportez-vous à SQL Server 2012 pour SharePoint Server 2013. Les résultats des tests sont les mêmes que dans SharePoint 2013.
Ce document est destiné à être utilisé conjointement par les implémenteurs de batteries de serveurs SharePoint Server et les administrateurs de base de données SQL Server, car SharePoint Server s’exécute souvent dans des environnements dans lesquels les bases de données sont gérées par des administrateurs de base de données SQL Server distincts. Il suppose une bonne maîtrise de SharePoint Server et de SQL Server.
Cet article part du principe que vous connaissez les concepts présentés dans la rubrique Gestion et dimensionnement de la capacité pour SharePoint Server 2013.
Processus de conception et de configuration des niveaux de stockage et de base de données pour SharePoint Server 2016 et versions ultérieures
Nous vous recommandons de diviser le processus de conception du niveau de stockage et de base de données selon les étapes suivantes. Ces sections fournissent des informations détaillées sur chaque étape de conception, y compris sur les besoins de stockage et les meilleures pratiques :
Collecter les besoins d’E/S, d’espace SQL Server et de stockage
Plusieurs facteurs architecturaux SharePoint Server influencent la conception du stockage. Les facteurs clés sont les suivants : la quantité de contenu, les fonctionnalités activées, les applications de service déployées, le nombre de batteries de serveurs et la disponibilité requise.
Avant de commencer à prévoir le stockage, vous devez savoir quelles bases de données SharePoint Server peut utiliser.
Dans cette section :
Comprendre SQL Server et les opérations d'E/S par seconde (IOPS)
Estimer les besoins en matière de stockage principal et d'IOPS
Estimer les besoins en matière de stockage et d'IOPS des applications de service
Bases de données utilisées par SharePoint Server
Les bases de données installées avec les serveurs SharePoint (Édition Abonnement, 2019 ou 2016) dépendent des applications de service utilisées dans l’environnement. Tous les environnements SharePoint Server s’appuient sur les bases de données système SQL Server. Cette section fournit un résumé des bases de données installées avec SharePoint Server. Pour plus d'informations sur les bases de données, voir Types et descriptions des bases de données dans SharePoint Server.
[!REMARQUE] Certains moteurs de base de données SharePoint Server et SQL Server, et certaines bases de données SQL Server Reporting Services (SSRS) ont des recommandations ou des exigences spécifiques en matière d'emplacement. Pour plus d'informations sur les emplacements de base de données, voir Types et descriptions des bases de données dans SharePoint Server. Le guide de référence rapide : Bases de données SharePoint Server 2016 et 2019 peut être téléchargé au format PDF ou Visio .
Les bases de données suivantes sont les bases de données système SharePoint Server et sont automatiquement installées.
Configuration
Contenu d’Administration Centrale
Contenu (une ou plusieurs)
La liste suivante montre les applications de service SharePoint Server dotées de bases de données :
Service Gestion des applications
Applications pour SharePoint
Business Data Connectivity
Métadonnées gérées
PerformancePoint Services
Project Server (SharePoint Server 2013 uniquement)
Service de recherche
Administration de la recherche
Création de rapports d’analyse
Analyse
Liens
Service Banque d’informations sécurisé
Service de traduction SharePoint
Service Power Pivot de SQL Server
Service d’états temporaires
Service de paramètres d’abonnement
Collection des données d’utilisation et d’intégrité
Service de profil utilisateur
Profils
Lien de mise en réseau
Synchronisation
Word Automation Services
La liste suivante présente les bases de données SharePoint Foundation 2013 :
Configuration
Contenu d’Administration Centrale
Contenu (une ou plusieurs)
Service Gestion des applications
Application de service de recherche :
Administration de la recherche
Création de rapports d’analyse (une ou plusieurs)
Analyse (une ou plusieurs)
Liens (une ou plusieurs)
Service Banque d’informations sécurisé
Application de service de paramètres d’abonnement (si activée via Windows PowerShell)
Service de collecte de données relatives à l’utilisation et à l’intégrité
Service de conversion Word
Si vous effectuez une intégration ultérieure avec SQL Server, votre environnement peut également inclure davantage de bases de données, comme dans le scénario suivant. SQL Server PowerPivot pour SharePoint peut uniquement être utilisée dans un environnement SharePoint Server 2016 si vous utilisez SQL Server 2016 RTM Enterprise Edition et SQL Server 2016 SQL Server Analysis Services (SSAS). En cas d’utilisation, vous devez également planifier la prise en charge de la base de données d’application Power Pivot et de la charge supplémentaire sur le système. Pour plus d'informations, téléchargez le nouveau livre blanc relatif au déploiement des compléments PowerPivot et Power View de SQL Server 2016 dans SharePoint 2016. Pour plus d'informations sur la configuration et le déploiement des fonctionnalités décisionnelles sur une batterie SharePoint Server 2016 à plusieurs serveurs, téléchargez Déploiement des compléments PowerPivot et Power View de SQL Server 2016 dans une batterie de serveurs SharePoint 2016 multiniveau.
Le plug-in SQL Server 2016 Reporting Services (SSRS) peut être utilisé avec n'importe quel environnement SharePoint Server 2016. Si vous utilisez le complément, prévoyez de prendre en charge les deux bases de données SQL Server Reporting Services et la charge supplémentaire requise pour SQL Server Reporting Services.
SQL Server 2012 PowerPivot pour SharePoint 2013 peut être utilisé dans un environnement SharePoint 2013 comprenant SQL Server 2008 R2 Enterprise Edition et SQL ServerAnalysis Services. En cas d’utilisation, vous devez également planifier la prise en charge de la base de données d’application Power Pivot et de la charge supplémentaire sur le système. Pour plus d’informations, consultez Planifier un déploiement PowerPivot dans une batterie de serveurs SharePoint, Power Pivot - Vue d’ensemble et Formation et Power View - Vue d’ensemble et Apprentissage.
Le plug-in SQL Server 2008 R2 Reporting Services (SSRS) peut être utilisé avec n'importe quel environnement SharePoint 2013. Si vous utilisez le plug-in, prévoyez de prendre en charge les deux bases de données SQL Server 2008 R2 Reporting Services et la charge supplémentaire requise pour SQL Server 2008 R2 Reporting Services.
Notes
L’intégration de SQL Server Reporting Services à SharePoint Server 2019 n’est plus prise en charge. Pour plus d’informations, consultez Serveur de rapports Reporting Services (mode SharePoint) et Combinaisons prises en charge de SharePoint et de serveur Reporting Services.
Comprendre SQL Server et les opérations d’E/S par seconde (IOPS)
Sur tout serveur qui héberge une instance SQL Server, il est important que le serveur obtienne la réponse la plus rapide possible du sous-système d'E/S.
Des disques ou des matrices plus nombreux et plus rapides fournissent suffisamment d’IOPS tout en maintenant une latence et une mise en file d’attente peu importantes sur tous les disques.
Vous ne pouvez pas ajouter d'autres types de ressource, comme un processeur ou de la mémoire, pour compenser la lenteur de réaction du sous-système d'E/S. Cependant, un tel ajout peut avoir un impact et provoquer des problèmes dans l'ensemble de la batterie de serveurs. Prévoyez une latence minimale avant le déploiement et surveillez les systèmes existants.
Avant de déployer une nouvelle batterie de serveurs, nous vous recommandons de comparer le sous-système d’E/S à l’aide de l’utilitaire Diskspd. Cet outil fonctionne sur toutes les versions de Windows Server avec toutes les versions de SQL Server. Pour plus d'informations, voir la page sur l'utilitaire Diskspd, un outil de tests de stockage fiable.
Les tests de contrainte fournissent également des informations utiles pour SQL Server. Pour plus d'informations, voir la page sur les tests d'évaluation de stockage avec DiskSpd.
Pour plus d'informations sur la façon d'analyser les besoins en matière d'IOPS dans le contexte de SQL Server, voir l'analyse des caractéristiques d'E/S et le dimensionnement des systèmes de stockage pour SQL Server Database Applications.
Estimer les besoins en matière de stockage principal et d’IOPS
Le stockage de la configuration et du contenu et les IOPS sont la couche de base à prévoir dans chaque déploiement SharePoint Server.
Stockage de la configuration et IOPS
Les besoins en stockage de la base de données de configuration et de la base de données de contenu Administration centrale ne sont pas importants. Nous recommandons d'allouer 2 Go à la base de données de configuration et 1 Go à la base de données de contenu Administration centrale. Au fil du temps, la base de données de configuration peut dépasser 1 Go. Toutefois, elle n'augmente que de 40 Mo environ toutes les 50 000 collections de sites.
Les journaux de transactions pour la base de données de configuration peuvent être volumineux. Nous vous recommandons de sauvegarder régulièrement le journal des transactions pour la base de données de configuration afin de forcer la troncation. Si vous utilisez SQL Server Always On sur des groupes de disponibilité ou la mise en miroir de base de données, nous vous recommandons également de maintenir la base de donnée utilisée en mode de récupération complète. Pour plus d’informations, voir le Journal des transactions (SQL Server).
Conseil
Si vous n’utilisez pas une solution SQL Server de haute disponibilité qui nécessite l’utilisation du modèle de récupération complète, vous pouvez envisager le remplacement de la base de données de configuration par le modèle de récupération simple.
Les besoins IOPS de la base de données de configuration et de la base de données de contenu d'administration centrale sont minimes.
Stockage de contenu et IOPS
Estimer le stockage et les IOPS requis pour les bases de données de contenu est une tâche approximative. En testant et en expliquant les informations suivantes, nous souhaitons vous aider à établir des estimations exploitables pour déterminer la taille initiale de votre déploiement. Toutefois, lorsque votre environnement sera opérationnel, vous redéfinirez probablement vos besoins en capacité en fonction des données de votre environnement réel.
Pour plus d'informations sur notre méthodologie de planification de capacité globale, voir la rubrique Gestion et dimensionnement de la capacité pour SharePoint Server 2013.
Formules d’estimation du stockage nécessaire pour les bases de données de contenu
La procédure suivante décrit comment estimer approximativement l’espace nécessaire pour stocker les bases de données de contenu, sans prendre en compte les fichiers journaux :
Utilisez la formule suivante pour estimer la taille de vos bases de données de contenu :
Taille de la base de données = ((D × V) × S) + (10 Ko × (L + (V × D)))
Notes
[!REMARQUE] La valeur 10 Ko utilisée dans la formule est une constante estimant approximativement la quantité de métadonnées nécessaires pour SharePoint Server. Si votre système nécessite une utilisation importante des métadonnées, vous pouvez augmenter cette constante.
Calculez le nombre de documents prévu. Cette valeur est représentée par D dans la formule.
La manière de calculer le nombre de documents est déterminée par les fonctionnalités utilisées. Par exemple, pour les Mes sites ou les sites de collaboration, nous vous recommandons de calculer le nombre de documents prévu pour chaque utilisateur et de le multiplier par le nombre d'utilisateurs. Pour les sites de gestion d'enregistrements ou de publication de contenu, vous pouvez calculer le nombre de documents gérés et générés par un processus.
Si vous effectuez une migration à partir d'un système actif, il peut être plus facile d'extrapoler votre taux de croissance et votre utilisation actuels. Si vous créez un système, examinez les partages de fichiers existants ou d'autres référentiels et faites une estimation en fonction du taux d'utilisation.
Estimez la taille moyenne des documents à stocker. Cette valeur est représentée par S dans la formule. Il peut être utile d'établir des valeurs moyennes pour les différents types ou groupes de sites. La taille de fichier moyenne peut varier considérablement entre les Mes sites, les référentiels de médias et les différents portails de service.
Estimez le nombre d'éléments de liste dans l'environnement. Cette valeur est représentée par L dans la formule.
Le nombre d'éléments de liste est plus difficile à estimer que le nombre de documents. Nous utilisons généralement une estimation de trois fois le nombre de documents (D), mais la formule d’estimation varie en fonction de la façon dont vous prévoyez d’utiliser vos sites.
Déterminez le nombre de versions approximatif. Estimez le nombre de versions moyen des différents documents d'une bibliothèque. Cette valeur est généralement beaucoup plus faible que le nombre de versions maximal autorisé. Elle est représentée par V dans la formule.
La valeur de V doit être supérieure à zéro.
Par exemple, utilisez cette formule et les caractéristiques du tableau suivant pour estimer l'espace de stockage nécessaire pour les fichiers de données d'une base de données de contenu dans un environnement de collaboration. Le résultat est que vous avez besoin d’environ 105 Go.
| Input | Valeur |
|---|---|
| Nombre de documents (D) | 200 000 Valeur obtenue en multipliant 10 000 utilisateurs par 20 documents |
| Taille des documents en moyenne (S) | 250 Ko |
| Éléments de liste (L) | 600 000 |
| Nombre de versions non actuelles (V) | 2 En supposant que le nombre de versions maximal autorisé est de 10 |
Taille de la base = (((200 000 x 2)) x 250) + ((10 Ko x (600 000 + (200 000 x 2))) = 110 000 000 Ko ou 105 Go
Notes
[!REMARQUE] La méthode de stockage des E/S de fichiers optimisées dans SharePoint Server consiste à fractionner un fichier en plusieurs parties qui sont stockées et mises à jour séparément. Ces parties sont diffusées ensemble quand un utilisateur demande le fichier. Cette méthode améliore les performances d'E/S, mais n'augmente généralement pas la taille du fichier. Toutefois, une petite augmentation de l’espace disque nécessaire peut être constatée pour les petits fichiers.
Fonctionnalités ayant un impact sur la taille des bases de données de contenu
Les fonctionnalités de Microsoft Office SharePoint Online Server suivantes peuvent affecter la taille des bases de données de contenu :
Corbeilles Tant qu'un document n'est pas totalement supprimé des corbeilles primaire et secondaire, il occupe de l'espace dans une base de données de contenu. Calculez le nombre de documents supprimés chaque mois pour déterminer l'effet des corbeilles sur la taille des bases de données de contenu.
Audit Les données d'audit peuvent rapidement poser problème et occuper un espace important d'une base de données de contenu, surtout si l'affichage de l'audit est activé. Pour limiter l'expansion de ces données, nous vous recommandons de n'activer l'audit que pour les événements qui le nécessitent pour des raisons réglementaires ou en vue de contrôles internes. Utilisez les indications suivantes pour estimer l'espace à réserver aux données d'audit :
Estimez le nombre de nouvelles entrées d'audit pour un site et multipliez le résultat par 2 Ko (les entrées sont généralement limitées à 4 Ko, avec une taille moyenne d'environ 1 Ko).
En fonction de l’espace que vous souhaitez allouer, déterminez le nombre de jours de journaux d’audit à conserver.
Notes
[!REMARQUE] Office Online Server est la nouvelle version d'Office Web Apps Server. L’utilisation d’Office Online Server avec SharePoint Server 2016, 2019, Édition Abonnement n’affecte pas la taille de la base de données de contenu. Pour déployer Office Online Server dans votre batterie de serveurs SharePoint Server 2016, voir Deploy Office Online Server.
Estimer les besoins en matière d’IOPS des bases de données de contenu
Les exigences d’IOPS pour les bases de données de contenu varient en fonction de la façon dont votre environnement est utilisé, de l’espace disque disponible et du nombre de serveurs dont vous disposez. En général, nous vous recommandons de comparer la charge de travail prévue dans votre environnement à l'une des solutions que nous avons testées. Pour plus d’informations et peut être appliqué à une version plus récente de SharePoint, voir Résultats et recommandations des tests de performances et de capacité (SharePoint Server 2013).
Lors de tests, nous avons constaté que les bases de données de contenu affichent généralement des valeurs comprises entre 0,05 IOPS/Go et 0,2 IOPS/Go environ. Nous nous sommes également rendu compte qu'il est approprié d'augmenter la valeur supérieure à 0,5 IOPS/Go. Cette proportion accrue est plus que nécessaire et peut être beaucoup plus que nécessaire dans votre environnement. Si vous utilisez la mise en miroir, cette proportion accrue entraîne beaucoup plus d’E/S que les bases de données de contenu primaires. N’oubliez pas que les bases de données de contenu mis en miroir ne sont jamais légères.
Estimer les besoins en matière de stockage et d’IOPS des applications de service
Une fois les besoins en matière de stockage de contenu et d’IOPS estimés, vous devez déterminer le stockage et les IOPS requis par les applications de service utilisées dans votre environnement.
Besoins en matière de stockage et d'IOPS des applications de service SharePoint Server
Pour estimer les besoins en matière de stockage des applications de service dans le système, vous devez d'abord connaître ces dernières et la façon dont vous allez les utiliser. Les applications de service qui sont disponibles dans SharePoint Server 2016 et qui comportent des bases de données sont répertoriées dans les tableaux suivants. Les données de stockage et d’IOPS pour toutes les applications de service dans SharePoint Server Édition d’abonnement, 2019 ou 2016 restent les mêmes que dans SharePoint Server 2010 et 2013.
Besoins en matière de stockage et d'IOPS des applications de service de recherche
| Database | Montée en charge | Nombre d’IOPS de disque | Taille du disque | 10 millions d’éléments | 100 millions d’éléments |
|---|---|---|---|---|---|
| Analyse | Une base de données pour 20 millions d’éléments IOPS SQL : 10 par DPS |
Moyen/élevé | Moyenne | 15 Go Journal de 2 Go |
110 Go 50 Go de journal |
| Liens | Une base de données pour 60 millions d’éléments IOPS SQL : 10 par million d’éléments |
Moyen | Moyenne | 10 Go Journal de 0,1 Go |
80 Go Journal de 5 Go |
| Création de rapports d’analyse | Divisé lorsque vous atteignez 100-300 Go | Moyen | Moyenne | Fonction de l’utilisation | Fonction de l’utilisation |
| Administration de la recherche | Une base de données | Faible | Petite | 0,4 Go Journal de 1 Go |
1 Go de données Journal de 2 Go |
Recommandations relatives aux besoins de stockage et aux IOPS des applications de service
| Application de service | Recommandation relative à l’estimation de la taille |
|---|---|
| Profil utilisateur | L'application de service de profil utilisateur est associée à trois bases de données : profils, synchronisation et liaison de mise en réseau. Remarque : Le test des exigences de stockage de la base de données de profil utilisateur et des recommandations d’IOPS n’est pas encore terminé. Nous vous invitons à consulter de nouveau cette page à une date ultérieure pour obtenir davantage d'informations. Pour plus d'informations sur la base de données de profils utilisateur, reportez-vous à Types et descriptions des bases de données dans SharePoint Server. |
| Service de métadonnées gérées | L'application de service de métadonnées gérées dispose d'une base de données. La taille de cette dernière dépend du nombre de types de contenu et de mots clés utilisés dans le système. De nombreux environnements incluent plusieurs instances de l'application de service de métadonnées gérées. |
| Service Banque d’informations sécurisé | La taille de la base de données d'application de service Banque d'informations sécurisée est déterminée par le nombre d'informations d'identification stockées dans la banque d'informations et par le nombre d'entrées dans la table d'audit. Nous vous recommandons d’allouer 5 Mo pour chaque 1 000 informations d’identification. Le nombre d'IOPS est faible. |
| Service d’états temporaires | L'application de service d'états temporaires dispose d'une base de données. Nous vous recommandons de lui allouer 1 Go. Le nombre d'IOPS est faible. |
| Word Automation Services | L'application de service Word Automation Services dispose d'une base de données. Nous vous recommandons de lui allouer 1 Go. Le nombre d'IOPS est faible. |
| PerformancePoint Services | L'application de service PerformancePoint Services dispose d'une base de données. Nous vous recommandons de lui allouer 1 Go. Le nombre d'IOPS est faible. |
| Service Business Data Connectivity | L'application Service Business Data Connectivity dispose d'une base de données. Cette dernière est de petite taille et une croissance significative est peu probable. Le nombre d'IOPS est faible. PerformancePoint Services n’est pas applicable à Subscription Edition. |
| Gestion des applications | L'application des service Gestion des applications dispose d'une base de données. Cette dernière est de petite taille et une croissance significative est peu probable. Le nombre d'IOPS est faible. |
| PowerPivot | L'application de service PowerPivot dispose d'une seule base de données. Cette base de données est de petite taille et n'a pas d'incidence significative en matière d'E/S. Nous vous recommandons d'utiliser le même nombre d'IOPS que pour la base de données de contenu SharePoint. Les bases de données de contenu ont des exigences d’E/S beaucoup plus élevées que la base de données d’application de service Power Pivot. |
Déterminer les besoins en disponibilité
La disponibilité correspond à la quantité d’environnement SharePoint Server perçue par les utilisateurs comme étant disponible. Un système est disponible s'il est robuste : les incidents affectant le service sont rares et une action immédiate et efficace est entreprise quand ils se produisent.
Les besoins en disponibilité peuvent augmenter considérablement les besoins en matière de stockage. Pour plus d'informations, voir Créer une architecture et une stratégie haute disponibilité pour SharePoint Server. Consultez également le livre blanc SQL Server 2012 Always On Guide d’architecture : création de solutions de haute disponibilité et de récupération d’urgence à l’aide de groupes de disponibilité Always On.
Choisir la version et l’édition de SQL Server
Nous vous recommandons, pour SharePoint Server Subscription Edition, 2019 ou 2016, d'envisager d'exécuter votre environnement sur l'édition Enterprise des serveurs SQL suivants afin de profiter des autres fonctionnalités de performance, de disponibilité, de sécurité et de gestion que ces versions offrent.
SQL Server 2019 (Édition d’abonnement SharePoint, 2019 et 2016)
SQL Server 2017 RTM (serveurs de SharePoint 2016 et 2019)
SQL Server 2016 (serveurs de SharePoint 2016 et 2019)
SQL Server 2014 avec Service Pack 1 (SP1) (SharePoint Server 2016 seulement)
Pour plus d’informations sur les avantages de ces versions, consultez Fonctionnalités prises en charge par les éditions de SQL Server 2014, Éditions et fonctionnalités prises en charge de SQL Server 2016, Éditions et fonctionnalités prises en charge de SQL Server 2017 et Éditions et fonctionnalités prises en charge de SQL Server 2019 (15.x)).
Pour SharePoint Server 2013, nous vous recommandons d’exécuter votre environnement sur l’édition Enterprise de SQL Server 2008 R2 avec Service Pack 1 (SP1), SQL Server 2012 ou SQL Server 2014 pour tirer parti des autres fonctionnalités de performances, de disponibilité, de sécurité et de gestion que ces versions offrent. Pour plus d'informations sur les avantages de l'édition Enterprise Edition de SQL Server 2008 R2 avec SP1, SQL Server 2012 et SQL Server 2014, reportez-vous à Fonctionnalités prises en charge par les éditions de SQL Server 2014, à Fonctionnalités prises en charge par les éditions de SQL Server 2012 et à Fonctionnalités prises en charge par les éditions de SQL Server 2008 R2.
Vous devez notamment prendre en compte vos besoins pour les fonctionnalités suivantes :
Compression de sauvegardes La compression de sauvegardes permet d'accélérer les sauvegardes SharePoint et est disponible dans SQL Server 2008 et version ultérieure. En définissant l'option de compression dans vos scripts de sauvegarde ou en configurant le serveur qui exécute SQL Server de manière à effectuer une compression par défaut, vous pouvez réduire considérablement la taille de vos sauvegardes de bases de données et de vos journaux expédiés. Pour plus d'informations, voir Compression de sauvegardes (SQL Server).
Notes
La compression de données SQL Server n'est pas prise en charge avec SharePoint Server, sauf pour les bases de données d'application de service de recherche.
Chiffrement transparent des données Si vos impératifs de sécurité nécessitent l'utilisation du chiffrement transparent des données, utilisez SQL Server Enterprise Edition.
Déploiement de contenu Si vous prévoyez d'utiliser la fonctionnalité de déploiement de contenu, utilisez plutôt SQL Server Enterprise Edition pour que le système puisse tirer profit des instantanés de base de données.
Notes
Si vous utilisez un fournisseur de stockage BLOB distant qui ne prend pas en charge les instantanés de base de données, vous ne pouvez pas les employer pour la sauvegarde ou le déploiement de contenu.
Stockage BLOB distant Si vous voulez tirer profit du stockage BLOB distant dans une base de données ou un emplacement hors des fichiers associés à chaque base de données de contenu, vous devez utiliser l’édition Enterprise de :
SharePoint Server Édition d’abonnement :
SQL Server 2016
SQL Server 2017 RTM
SQL Server 2019
SharePoint Server 2019 :
SQL Server 2016
SQL Server 2017 RTM
SQL Server 2019
SharePoint Server 2016 :
SQL Server 2014 (SP1)
SQL Server 2016
SQL Server 2017 RTM
SQL Server 2019
SharePoint 2013 :
SQL Server 2008 R2 avec SP1
SQL Server 2012 Enterprise Edition
Gouverneur de ressources Le gouverneur de ressources est une technologie introduite dans SQL Server 2008 pour vous permettre de gérer les charges de travail et les ressources SQL Server en définissant des limites de consommation des ressources pour les demandes entrantes. Il vous permet de différencier les charges de travail et d'allouer les ressources de processeur et de mémoire en fonction de la demande et des limites spécifiées. Pour plus d’informations sur l’utilisation de Resource Governor, consultez Resource Governor.
Nous vous conseillons d'utiliser le gouverneur de ressources avec SharePoint Server pour :
limiter les ressources de SQL Server que consomment les serveurs web ciblés par le composant d'analyse de recherche. En règle générale, nous recommandons d'imposer au composant d'analyse une limite de 10 % des ressources de processeur lorsque le système est en charge ;
surveiller les ressources consommées par chaque base de données du système. Par exemple, vous pouvez utiliser le gouverneur de ressources pour vous aider à répartir au mieux les bases de données sur les ordinateurs exécutant SQL Server.
Microsoft Power Pivot pour SharePoint Permet aux utilisateurs de partager et de collaborer sur des modèles de données et des analyses générés par l’utilisateur dans Excel sur le web tout en actualisant automatiquement ces analyses. Vous devez disposer d’Office sur le web pour utiliser Excel sur le web avec Power Pivot pour SharePoint et SharePoint Server 2016. Vous pouvez utiliser SQL Server 2014 (SP1) ou SQL Server 2016 RTM Enterprise Edition et SQL Server Analysis Services pour utiliser les fonctionnalités décisionnelles avec SharePoint Server 2016. Toutefois, vous ne pouvez utiliser PowerPivot pour SharePoint qu'avec SQL Server 2016 RTM, et non avec (SP1).
PowerPivot pour SharePoint 2013 Permet aux utilisateurs de partager et de collaborer sur une analyse et des modèles de données générés par l'utilisateur dans Excel et dans le navigateur, tout en actualisant automatiquement ces analyses. Il est inclus dans SQL Server 2008 R2 Analysis Services (SSAS) Datacenter et Enterprise Edition, SQL Server 2012 SP1 Analysis Services (SSAS) Enterprise Edition, ainsi que SQL Server 2014 Analysis Services (SSAS) Enterprise et Business Intelligence Edition.
Concevoir l’architecture de stockage en fonction des besoins en capacité et en matière d’opérations d’E/S
L’architecture de stockage et les types de disque choisis pour l’environnement peuvent avoir un impact sur les performances du système.
Dans cette section :
Choisir une architecture de stockage
SharePoint Server prend en charge les architectures de stockage DAS (Direct Attached Storage), SAN (Storage Area Network) et NAS (Network Attached Storage), bien que NAS soit uniquement pris en charge pour une utilisation avec des bases de données de contenu configurées pour utiliser le stockage BLOB distant. Votre choix dépend de facteurs au sein de votre solution métier et de votre infrastructure existante.
L'architecture de stockage doit répondre à vos besoins en disponibilité et fonctionner correctement en matière d'IOPS et de latence. Le système est pris en charge s'il renvoie invariablement le premier octet de données en l'espace de 20 millisecondes (ms).
Stockage à connexion directe (DAS)
Le DAS est un système de stockage numérique qui est directement connecté à un serveur ou à une station de travail, sans réseau de stockage intermédiaire. Les disques physiques DAS sont de type SAS (Serial Attached SCSI) et SATA (Serial Attached ATA).
En général, nous vous recommandons de choisir une architecture DAS quand une plateforme de stockage partagé ne peut pas garantir un temps de réponse de 20 ms et une capacité suffisante pour un nombre d'IOPS moyen ou maximal.
Réseau de zone de stockage (SAN)
L’architecture SAN permet de relier des périphériques de stockage distants (tels que des bases de disques et des bibliothèques de bandes) à des serveurs de telle sorte que ces périphériques semblent être connectés en local au système d’exploitation (par exemple, mémoire de blocs).
En général, nous vous recommandons de choisir un SAN si les avantages du stockage partagé sont importants pour votre organisation.
Les avantages du stockage partagé incluent :
réallocation plus facile du stockage de disque entre les serveurs ;
prise en charge de plusieurs serveurs possible ;
aucune limite sur le nombre de disques accessibles.
Stockage connecté au réseau (NAS)
Une unité NAS est un ordinateur autonome connecté à un réseau. Son seul but est de mettre à disposition des autres dispositifs du réseau des services de stockage de données fichier. Le système d'exploitation et d'autres logiciels de l'unité NAS fournissent les fonctionnalités de stockage de données, de systèmes de fichiers et d'accès aux fichiers, ainsi que la gestion de ces fonctionnalités (stockage de fichiers par exemple).
Notes
[!REMARQUE] Le NAS n'est pris en charge qu'avec les bases de données de contenu configurées pour utiliser le stockage BLOB distant. L'architecture de stockage en réseau doit répondre à un ping en l'espace d'1 ms et renvoyer le premier octet de données en l'espace de 20 ms. Cette restriction ne s'applique pas au fournisseur FILESTREAM SQL Server local, car il ne stocke les données que localement sur le même serveur.
Notes
Il existe une certaine confusion quant à savoir si vous utilisez iSCSI (Internet Small Computer System Interface) et supposez qu’il s’agit d’un protocole NAS. Si vous accédez à ce stockage iSCSI par le biais du Système de fichiers Internet commun (CFIS), il s’agit d’un protocole NAS. Cela signifie que vous ne pouvez pas utiliser ce stockage avec des bases de données de contenu si elles ne sont pas configurées pour utiliser RBS. Toutefois, si vous accédez à ce stockage iSCSI via un disque dur attaché localement, il est considéré comme une architecture SAN. Cela signifie que vous pouvez l’utiliser avec nas.
Choisir des types de disque
Les types de disque utilisés dans le système peuvent avoir un impact sur la fiabilité et les performances. Les lecteurs plus importants augmentent le temps d'accès moyen. SharePoint Server prend en charge les types de lecteur suivants :
SCSI (Small Computer System Interface)
SATA (Serial Advanced Technology Attachment)
SAS (Serial Attached SCSI)
FC (Fibre Channel)
IDE (Integrated Device Electronics)
SSD (Solid State Drive) ou disque flash
Choisir des types RAID
La technologie RAID (Redundant Array of Independent Disks) est souvent utilisée à la fois pour améliorer les performances des différents disques (agrégation des données par bande sur plusieurs disques) et pour fournir une protection contre une défaillance d’un disque.
Tous les types RAID sont pris en charge par SharePoint Server. Toutefois, nous vous recommandons d'utiliser RAID 10 ou une solution RAID propre au fournisseur présentant des performances équivalentes.
Lorsque vous configurez une matrice RAID, assurez-vous d’aligner le système de fichiers sur l’offset qui est fourni par le fournisseur.
Pour plus d'informations sur l'approvisionnement RAID pour SQL Server, voir RAID.
Estimer les besoins en mémoire
La quantité de mémoire nécessaire pour SharePoint Server est directement liée à la taille des bases de données de contenu hébergées sur un serveur exécutant SQL Server.
Lorsque vous ajoutez des applications de service et des fonctionnalités, vos besoins peuvent augmenter. Le tableau suivant indique la quantité de mémoire recommandée.
| Taille combinée de bases de données de contenu | RAM recommandée pour l'ordinateur exécutant SQL Server |
|---|---|
| Minimum pour les déploiements de production de petite taille | 8 Go |
| Minimum pour les déploiements de production de taille moyenne | 16 Go |
| Recommandation pour 2 téraoctets maximum | 32 Go |
| Recommandation pour une taille comprise entre 2 et 5 téraoctets | 64 Go |
| Recommandation pour plus de 5 téraoctets | Une RAM supplémentaire de plus de 64 Go peut améliorer la vitesse de mise en cache de SQL Server |
Notes
[!REMARQUE] Ces valeurs sont supérieures aux valeurs minimales recommandées pour SQL Server en raison de la distribution des données nécessaires pour un environnement SharePoint Server. Pour plus d’informations sur la configuration système requise pour SQL Server, consultez Configuration matérielle et logicielle requise pour l’installation de SQL Server 2014 et Configuration matérielle et logicielle requise pour l’installation de SQL Server pour SQL Server 2016 et 2017.
Pour plus d'informations sur les limites de capacité et les spécifications de SQL Server, consultez Limites de capacité de calcul par édition de SQL Server et Spécifications de capacité maximale pour SQL Server.
D'autres facteurs peuvent influencer la mémoire requise :
utilisation de la mise en miroir SQL Server ;
utilisation fréquente de fichiers de plus de 15 mégaoctets (Mo).
Comprendre les exigences en matière de topologie du réseau
Planifiez les connexions réseau au sein des batteries de serveurs et entre elles. Nous vous recommandons d'utiliser un réseau présentant une faible latence.
La liste suivante indique quelques meilleures pratiques et recommandations :
Tous les serveurs de la batterie de serveurs doivent présenter une latence et une bande passante LAN pour le serveur exécutant SQL Server. La latence ne doit pas être supérieure à 1 milliseconde.
Nous déconseillons d'utiliser une topologie de réseau étendu (WAN, Wide Area Network), dans laquelle un serveur exécutant SQL Server est déployé à distance des autres composants de la batterie de serveurs sur un réseau présentant une latence supérieure à 1 ms. Cette topologie n'a en effet pas été testée.
Prévoyez un réseau WAN adéquat si vous envisagez d'utiliser la suite de mise en œuvre Always On de SQL Server, la mise en miroir, l'expédition de journaux ou la mise en grappe Failover pour maintenir un site distant à jour.
Nous recommandons que les serveurs web et les serveurs d'applications disposent de deux cartes réseau : une pour gérer le trafic utilisateur et l'autre pour gérer les communications avec les serveurs exécutant SQL Server.
Notes
Si vous utilisez iSCSI, vérifiez que chaque carte réseau est dédiée à la communication réseau ou à iSCSI, et pas aux deux.
Configurer SQL Server
Les sections suivantes décrivent comment planifier la configuration de SQL Server pour SharePoint Server.
Dans cette section :
Estimer le nombre de serveurs nécessaires
SharePoint Server est normalement conçu pour tirer profit de la montée en charge de SQL Server. Par exemple, SharePoint Server peut présenter de meilleures performances avec de nombreux serveurs de taille moyenne exécutant SQL Server qu'avec plusieurs gros serveurs.
Placez toujours SQL Server sur un serveur dédié qui n'exécute aucun autre rôle de batterie de serveurs ou n'héberge pas de base de données pour une autre application. La seule exception à cette recommandation concerne le déploiement du système sur un serveur autonome pour un développement ou un environnement de test non axé sur les performances. Même si SQL Server peut être exécuté sur le même serveur que SharePoint, nous vous recommandons de l'exécuter sur un serveur distinct pour améliorer les performances.
Les instructions suivantes sont des conseils généraux pour savoir quand déployer un serveur supplémentaire qui exécutera une instance SQL Server :
Ajoutez un autre serveur de base de données lorsque vous avez plus de quatre serveurs Web qui fonctionnent à pleine capacité.
Ajoutez un autre serveur de base de données lorsque votre serveur actuel a atteint ses limites de ressources effectives de RAM, de CPU, de débit d'E/S de disque, de capacité de disque ou de débit du réseau.
Pour plus d'informations, voir Limites de capacité de calcul par l'édition de SQL Server et Spécifications des capacités maximales pour SQL Server.
Pour favoriser le stockage sécurisé des informations d'identification lorsque vous exécutez l'application de service Banque d'informations sécurisée, nous vous recommandons d'héberger la base de données Banque d'informations sécurisée sur une instance de base de données distincte dont l'accès est limité à un seul administrateur.
Configurer le stockage et la mémoire
Sur le serveur exécutant SQL Server, nous recommandons que le cache L2 de chaque processeur dispose d'un minimum de 2 Mo pour améliorer les ressources de mémoire.
Suivre les recommandations de configuration du stockage du fournisseur
Pour des performances optimales lorsque vous configurez un groupe de stockage physique, respectez les recommandations de configuration du matériel données par le fournisseur du dispositif de stockage plutôt que de vous référer aux valeurs par défaut du système d’exploitation.
Si votre fournisseur ne vous a pas donné d'instruction, nous vous recommandons d'utiliser les cmdlets de stockage PowerShell disponibles pour Windows Server 2012 R2. Pour plus d'informations, consultez l'article sur les cmdlets de stockage dans Windows PowerShell.
Fournir autant de ressources que possible
Assurez-vous que les canaux d'E/S SQL Server vers les disques ne sont pas partagés par d'autres applications, comme le fichier de pagination et les journaux Internet Information Services (IIS).
Fournissez autant de bande passante de bus que possible. Une bande passante de bus plus importante améliore la fiabilité et les performances. Le disque n'est en effet pas le seul utilisateur de la bande passante du bus : vous devez également tenir compte de l'accès au réseau par exemple.
Définir les options SQL Server
Les options et paramètres SQL Server suivants doivent être configurés avant le déploiement de SharePoint Server.
N’activez pas les statistiques de création automatique sur un serveur qui héberge SQL Server et prend en charge SharePoint Server. SharePoint Server configure les paramètres requis lors de l'approvisionnement et de la mise à niveau. La création automatique de statistiques peut modifier le plan d’exécution d’une requête d’une instance de SQL Server à une autre instance de SQL Server. Par conséquent, pour offrir une assistance uniforme à tous les clients, SharePoint Server fournit pour les requêtes les conseils codés nécessaires pour obtenir les meilleures performances dans tous les scénarios.
Pour garantir des performances optimales, il est vivement recommandé de définir le degré maximal de parallélisme (MAXDOP) sur 1 instance SQL Server qui héberge des bases de données SharePoint Server. Pour plus d'informations sur la définition du degré maximal de parallélisme, voir Configurer l'option de configuration du serveur Degré maximal de parallélisme.
Configurer les bases de données
Les instructions ci-dessous décrivent les meilleures pratiques à mettre en place lorsque vous configurez chaque base de données de votre environnement.
Séparer et classer les données par ordre de priorité sur différents disques
Idéalement, vous devez placer la base de données tempdb, les bases de données de contenu, la base de données, les bases de données de recherche et les journaux des transactions de SQL Server 2019, SQL Server 2017 RTM, SQL Server 2016, SQL Server 2014 (SP1), SQL Server 2012 et SQL Server 2008 R2 avec SP1 sur des disques durs physiques distincts.
La liste suivante indique quelques meilleures pratiques et recommandations pour le classement par ordre de priorité des données :
Lorsque vous classez les données par ordre de priorité sur les disques plus rapides, respectez l’ordre suivant :
Fichiers de données tempdb et journaux de transactions
Fichiers journaux des transactions de base de données
Bases de données de recherche, à l’exception de la base de données d’administration de recherche
Fichiers de données de base de données
Pour un site portail largement destiné à la lecture, donnez la priorité aux données par rapport aux journaux.
Les tests et les données client montrent que les performances de la batterie de serveurs SharePoint Server peuvent être entravées par des E/S disque insuffisantes pour tempdb. Pour éviter ce problème, allouez des disques dédiés à tempdb. Si une charge de travail élevée est prévue ou constatée (l'action de lecture ou d'écriture nécessite plus de 20 ms en moyenne), vous pouvez réduire le goulot d'étranglement en répartissant les fichiers sur plusieurs disques ou en remplaçant ces derniers par des disques plus rapides.
Pour de meilleures performances, placez tempdb sur un tableau RAID 10. Le nombre de fichiers de données tempdb doit être égal au nombre de processeurs principaux, et les fichiers de données tempdb doivent être définis à une taille égale. Comptez les processeurs double cœur comme deux processeurs à cet effet. Comptez chaque processeur qui prend en charge l’hyperthreading comme processeur unique. Pour plus d’informations, consultez Optimisation des performances tempdb.
Répartissez les données de base de données et les fichiers journaux de transactions sur différents disques. Si des fichiers doivent partager des disques parce qu'ils sont trop petits pour justifier l'utilisation d'une bande ou d'un disque entier ou parce que vous manquez d'espace disque, placez sur le même disque des fichiers ayant des modèles d'utilisation différents pour réduire les demandes d'accès simultanées.
Consultez votre fournisseur de matériel de stockage pour plus d’informations sur la manière de configurer les journaux et les bases de données de recherche pour optimiser l’écriture dans votre solution de stockage.
Utiliser plusieurs fichiers de données pour les bases de données de contenu
Suivez ces recommandations pour optimiser les performances :
Créez uniquement des fichiers dans le groupe de fichiers primaire de la base de données.
Répartissez les fichiers sur des disques distincts.
Le nombre de fichiers de données doit être inférieur ou égal au nombre de processeurs principaux. Comptez les processeurs double cœur comme deux processeurs à cet effet. Comptez chaque processeur qui prend en charge l’hyperthreading comme processeur unique.
Créez des fichiers de données de taille équivalente.
Importante
Bien que vous puissiez utiliser les outils de sauvegarde et de récupération intégrés dans SharePoint Server pour sauvegarder et restaurer plusieurs fichiers de données, si vous effectuez un remplacement dans un même emplacement, les outils ne peuvent pas restaurer plusieurs fichiers de données vers un autre emplacement. Pour cette raison, nous vous recommandons vivement d'utiliser les outils de sauvegarde et de récupération SQL Server en cas d'emploi de plusieurs fichiers de données pour une base de données de contenu. Pour plus d'informations sur la sauvegarde et la restauration avec SharePoint Server, voir Planifier la sauvegarde et la récupération dans SharePoint Server.
Pour plus d'informations sur la création et la gestion des groupes de fichiers, voir Architecture des fichiers et des groupes de fichiers.
Limiter la taille des bases de données de contenu pour faciliter la gestion
Prévoyez un dimensionnement des bases de données permettant de faciliter la gestion et la mise à niveau de votre environnement, ainsi que d’améliorer les performances.
Pour garantir les performances du système, nous vous recommandons de limiter la taille des bases de données de contenu à 200 Go, sauf dans le cas de scénarios et de conditions d'utilisation spécifiques prenant en charge des tailles plus importantes. Pour plus d’informations sur les limites de taille de base de données de contenu, consultez la section « Limites de base de données de contenu » dans Limites et limites logicielles pour SharePoint Server 2016 et 2019.
Nous recommandons généralement qu'une collection de sites ne dépasse pas 100 Go, sauf s'il s'agit de la seule collection de sites dans la base de données, afin que vous puissiez utiliser les outils de sauvegarde précise SharePoint Server pour la déplacer vers une autre base de données si nécessaire.
Gérer de manière proactive la croissance des fichiers de données et des fichiers journaux
Nous vous recommandons de gérer de manière proactive la croissance des fichiers de données et des fichiers journaux en appliquant les recommandations suivantes :
Dans la mesure du possible, augmentez d’avance la taille de tous les fichiers de données et fichiers journaux jusqu’à atteindre la taille finale prévue.
Nous vous recommandons d'activer la croissance automatique pour des raisons de sécurité. N'utilisez pas les paramètres de croissance automatique par défaut. Suivez les indications ci-après pour configurer la croissance automatique :
Si vous envisagez d'utiliser des bases de données de contenu qui dépassent la taille recommandée (200 Go), définissez la valeur de croissance automatique des bases de données sur une valeur fixe (en mégaoctets) au lieu d'un pourcentage. Ce paramètre réduit la fréquence à laquelle SQL Server augmente la taille d’un fichier. L'augmentation de la taille d'un fichier est une action bloquante qui suppose de remplir le nouvel espace par des pages vides.
Si la taille calculée de la base de données de contenu n’est pas censée atteindre la taille maximale recommandée de 200 Go au cours de l’année suivante, définissez-la sur la taille maximale que la base de données devrait atteindre dans un an ( avec une marge d’erreur supplémentaire de 20 % ) à l’aide de la propriété ALTER DATABASE MAXSIZE . Vérifiez régulièrement que ce paramètre est toujours approprié en vous appuyant sur les taux de croissance passés.
Maintenez un niveau d'espace disque disponible d'au moins 25 % sur les disques pour gérer la croissance et les modèles de pics d'utilisation. Si vous gérez la croissance en ajoutant des disques à une matrice RAID ou en allouant davantage d'espace, surveillez étroitement la taille du disque pour éviter le manque d'espace.
Valider et surveiller les performances de stockage et de SQL Server
Effectuez des tests afin de vérifier que les performances et la solution de sauvegarde de votre matériel sont conformes à vos contrats de niveau de service (SLA). Testez notamment le sous-système d'E/S de l'ordinateur exécutant SQL Server pour vous assurer que les performances sont satisfaisantes.
Testez la solution de sauvegarde utilisée pour vérifier qu'elle parvient à sauvegarder le système dans la fenêtre de maintenance disponible. Si elle n'est pas conforme aux contrats SLA dont votre entreprise a besoin, envisagez une solution de sauvegarde incrémentielle comme Microsoft System Center Data Protection Manager.
Il est important de suivre les composants de ressources suivants sur les serveurs exécutant SQL Server : processeur, mémoire, taux d'accès au cache et sous-système d'E/S. Si des composants semblent lents ou surchargés, analysez la stratégie à adopter en fonction de la charge de travail actuelle et à venir. Pour plus d’informations, consultez la section Surveiller et régler les performances.
La section suivante répertorie les compteurs de performances que nous vous recommandons d'utiliser pour surveiller les performances des bases de données SQL Server s'exécutant dans votre environnement SharePoint Server. Elle précise également des valeurs appropriées approximatives pour chaque compteur.
Pour plus de détails sur la surveillance des performances et sur l'utilisation des compteurs de performances, voir les articles Analyseur de performances Windows et Configurer l'analyse des performances.
Compteurs SQL Server à surveiller
Surveillez les compteurs SQL Server suivants pour vérifier l'intégrité de vos serveurs :
General statistics This object provides counters to monitor general server-wide activity, such as the number of current connections and the number of users connecting and disconnecting per second from computers that are running an instance of SQL Server. Consider monitoring the following counter:
- Connexions utilisateur Ce compteur indique le nombre de connexions utilisateur à votre ordinateur exécutant SQL Server. Si ce nombre augmente de 500 % par rapport à votre base de référence, vous pouvez constater une réduction des performances.
Bases de données Cet objet fournit des compteurs pour surveiller les opérations de copie en bloc, le débit de sauvegarde et de restauration, et les activités du journal des transactions. Surveillez les transactions et le journal des transactions pour déterminer le nombre d'activités utilisateur en cours dans la base de données et le niveau de remplissage du journal des transactions. Le nombre d'activités utilisateur permet de déterminer les performances de la base de données et a un impact sur la taille du journal, le verrouillage et la réplication. Surveiller l'activité de journal de détails bas pour évaluer l'activité utilisateur et l'utilisation des ressources peut vous aider à identifier les goulots d'étranglement des performances. Pensez à surveiller le compteur suivant :
- Transactions/s Ce compteur indique le nombre de transactions par seconde pour une base de données précise ou pour l'ensemble du serveur. Ce nombre sert de référence et vous aide à résoudre les problèmes.
Verrous Cet objet fournit des informations sur les verrous SQL Server des différents types de ressource. Pensez à surveiller les compteurs suivants :
Temps d'attente moyen (ms) Ce compteur indique le temps d'attente moyen de chaque demande de verrou ayant abouti à une attente.
Temps d'attente des verrous (ms) Ce compteur indique le temps d'attente des verrous au cours de la dernière seconde.
Attentes de verrous/s Ce compteur indique le nombre de verrous par seconde qui n'ont pu être satisfaits immédiatement et ont dû attendre des ressources.
Nombre d'interblocages/s Ce compteur indique le nombre d'interblocages par seconde sur l'ordinateur exécutant SQL Server. Ce nombre ne doit pas augmenter au-dessus de 0.
Verrous internes Cet objet fournit des compteurs pour surveiller des verrous de ressource SQL Server internes appelés verrous internes. Surveiller les verrous internes pour évaluer l'activité utilisateur et l'utilisation des ressources peut vous aider à identifier les goulots d'étranglement des performances. Pensez à surveiller les compteurs suivants :
Temps d'attente moyen d'un verrou interne (ms) Ce compteur indique le temps d'attente moyen des demandes de verrou interne ayant abouti à une attente.
Attentes de verrous internes/s Ce compteur indique le nombre de demandes de verrou interne qui n'ont pas pu être immédiatement satisfaites.
Statistiques SQL Cet objet fournit des compteurs pour surveiller la compilation et le type des demandes envoyées à une instance SQL Server. Surveiller le nombre de compilations et de recompilations de requête et le nombre de lots reçus par une instance SQL Server vous donne une indication de la rapidité avec laquelle SQL Server traite les requêtes utilisateur et de l'efficacité avec laquelle l'optimiseur de requêtes traite les requêtes. Pensez à surveiller les compteurs suivants :
Compilations SQL/s Ce compteur indique le nombre de fois par seconde où le chemin d'accès au code de compilation est indiqué.
Recompilations SQL/s Ce compteur indique le nombre de recompilations d'instruction par seconde.
Gestionnaire de tampons Cet objet fournit des compteurs pour surveiller comment SQL Server utilise la mémoire afin de stocker des pages de données, des structures de données internes et le cache de procédures, ainsi que des compteurs pour surveiller les E/S physiques lorsque SQL Server lit et écrit des pages de base de données. Pensez à surveiller le compteur suivant :
Taux d'accès au cache des tampons
Ce compteur indique le pourcentage de pages trouvées dans le cache des tampons sans avoir à lire le disque. Le taux correspond au nombre total d'accès au cache divisé par le nombre total de recherches dans le cache sur les quelques derniers milliers d'accès aux pages. La lecture du cache étant beaucoup moins onéreuse que la lecture à partir du disque, il est souhaitable que ce taux soit élevé. En général, vous pouvez l'augmenter en allouant davantage de mémoire à SQL Server.
Cache du plan Cet objet fournit des compteurs pour surveiller comment SQL Server utilise la mémoire afin de stocker des objets tels que des procédures stockées, des instructions Transact-SQL préparées ou non et des déclencheurs. Pensez à surveiller le compteur suivant :
Taux d'accès au cache
Ce compteur indique le rapport entre les accès au cache et les recherches de plans.
Compteurs de serveur physique à surveiller
Surveillez les compteurs suivants pour vous assurer de l'intégrité de vos ordinateurs exécutant SQL Server :
Processeur : Pourcentage de temps processeur : _Total Ce compteur indique le pourcentage de temps que le processeur consacre à l'exécution de processus d'application ou de système d'exploitation, à l'exclusion des processus inactifs. Sur l'ordinateur exécutant SQL Server, la valeur de ce compteur doit être maintenue entre 50 % et 75 %. En cas de surcharge constante, vérifiez s’il y a une activité de processus anormale ou si le serveur a besoin de davantage de processeurs.
Système : Longueur de la file du processeur Ce compteur indique le nombre de threads dans la file du processeur. Surveillez-le pour vérifier que sa valeur demeure inférieure à deux fois le nombre de processeurs.
Mémoire : Mégaoctets disponibles Ce compteur indique la quantité de mémoire physique, en mégaoctets, disponible pour les processus en cours d'exécution sur l'ordinateur. Surveillez-le pour vérifier que le niveau de mémoire RAM physique disponible total est au moins égal à 20 %.
Mémoire : Pages/s Ce compteur indique la vitesse à laquelle les pages sont lues à partir du disque ou écrites sur celui-ci pour résoudre les erreurs de défaut de page matérielle. Surveillez-le pour vérifier que sa valeur demeure inférieure à 100.
Pour plus d’informations et des méthodes de résolution des problèmes de mémoire, consultez les ressources suivantes :
SQL Server 2014 (SP1) -Surveiller l'utilisation de la mémoire
SQL Server 2017, SQL Server 2017 et SQL Server 2019 -Surveiller l’utilisation de la mémoire
Pour obtenir plus d'informations et connaître les méthodes de résolution des problèmes liés à la mémoire, voir Surveillance de l'utilisation de la mémoire pour SQL Server 2008 R2 avec SP1, Surveiller l'utilisation de la mémoire pour SQL Server 2012 et Surveiller l'utilisation de la mémoire pour SQL Server 2014.
Compteurs de disque à surveiller
Surveillez les compteurs suivants pour vous assurer de l'intégrité des disques. Les valeurs suivantes représentent des valeurs mesurées au fil du temps, pas des valeurs qui se produisent pendant un pic soudain et non des valeurs basées sur une seule mesure.
Disque physique : % de temps disque : DataDrive Ce compteur indique le pourcentage de temps écoulé pendant lequel le lecteur de disque sélectionné est occupé à traiter les demandes de lecture ou d’écriture. Il s’agit d’un indicateur général de la disponibilité du disque. Si le compteur PhysicalDisk : % Disk Time est élevé (plus de 90 %), vérifiez le compteur PhysicalDisk : Longueur de file d’attente du disque actuel pour voir le nombre de demandes système en attente d’accès au disque. Le nombre de demandes d’E/S en attente ne doit pas dépasser 1,5 à 2 fois le nombre de broches qui composent le disque physique.
Disque logique : Transferts disque/s Ce compteur indique la vitesse à laquelle les opérations de lecture et d'écriture sont effectuées sur le disque. Utilisez-le pour surveiller les tendances de croissance et effectuer des prévisions en conséquence.
Disque logique : Lectures disque, octets/s et Disque logique : Écritures disque, octets/s Ces compteurs indiquent la vitesse de transfert des octets à partir du disque pendant les opérations de lecture ou d'écriture.
Disque logique : Moy. disque, octets/lecture Ce compteur indique le nombre moyen d'octets transférés à partir du disque pendant les opérations de lecture. Cette valeur peut refléter la latence de disque : plus les opérations de lecture sont importantes, plus la latence est susceptible d'augmenter légèrement.
Disque logique : Moy. disque, octets/écriture Ce compteur indique le nombre moyen d'octets transférés vers le disque pendant les opérations d'écriture. Cette valeur peut refléter la latence de disque : plus les opérations d'écriture sont importantes, plus la latence est susceptible d'augmenter légèrement.
Disque logique : Taille de file d'attente du disque actuelle Ce compteur indique le nombre de demandes qui sont en attente sur le disque au moment où les données de performances sont collectées. Pour ce compteur, plus les valeurs sont petites, plus la situation est convenable. Les valeurs supérieures à 2 par disque peuvent indiquer un goulot d'étranglement et doivent être analysées. Par conséquent, une valeur allant jusqu’à 8 est acceptable pour une unité logique (LUN) composée de quatre disques. Les goulots d'étranglement peuvent créer un journal des travaux en souffrance susceptible de s'étendre au-delà du serveur qui accède actuellement au disque et de se traduire par de longs temps d'attente pour les utilisateurs. Pour résoudre un goulot d'étranglement, vous pouvez ajouter des disques à la matrice RAID, remplacer les disques existants par des disques plus rapides ou déplacer une partie des données vers d'autres disques.
Disque logique : Longueur moyenne de la file d’attente du disque Ce compteur indique le nombre moyen de demandes de lecture et d’écriture qui ont été mises en file d’attente pour le disque sélectionné pendant l’intervalle de l’exemple. La règle est qu’il doit y avoir au moins deux demandes de lecture et d’écriture en attente par broche. Toutefois, ce nombre de requêtes peut être difficile à mesurer en raison de la virtualisation du stockage et des différences de niveaux RAID entre les configurations. Recherchez des longueurs de file d’attente de disque supérieures à la moyenne en combinaison avec des latences de disque supérieures à la moyenne. Cette combinaison peut indiquer que le cache de la baie de stockage est surexploité ou que le partage de broches avec d’autres applications affecte les performances.
Disque logique : Moyenne disque s/lecture et Disque logique : Moyenne disque s/écriture Ces compteurs indiquent le temps moyen, en secondes, d'une opération de lecture ou d'écriture sur le disque. Surveillez-les pour vérifier que leurs valeurs demeurent inférieures à 85 % de la capacité du disque. Le temps d'accès au disque augmente de manière exponentielle si les opérations de lecture ou d'écriture représentent plus de 85 % de la capacité du disque. Pour déterminer la capacité propre à votre configuration matérielle, reportez-vous à la documentation du fournisseur ou utilisez l'utilitaire Diskspd, un outil de tests de stockage qui permet de la calculer. Pour plus d’informations, consultez Diskspd : A Robust Storage Performance Tool.
Disque logique : Moy. Disque s/lecture Ce compteur indique la durée moyenne, en secondes, d’une opération de lecture à partir du disque. Sur un système bien réglé, les valeurs idéales sont comprises entre 1 et 5 ms pour les journaux (idéalement 1 ms sur un tableau mis en cache) et de 4 à 20 ms pour les données (idéalement inférieures à 10 ms). Des latences plus élevées peuvent se produire pendant les heures de pointe. Toutefois, si des valeurs élevées se produisent régulièrement, vous devez examiner la cause.
Disque logique : Moy. Disque s/écriture Ce compteur indique la durée moyenne, en secondes, d’une opération d’écriture sur le disque. Sur un système bien réglé, les valeurs idéales sont comprises entre 1 et 5 ms pour les journaux (idéalement 1 ms sur un tableau mis en cache) et de 4 à 20 ms pour les données (idéalement inférieures à 10 ms). Des latences plus élevées peuvent se produire pendant les heures de pointe. Toutefois, si des valeurs élevées se produisent régulièrement, vous devez examiner la cause.
Lorsque vous utilisez des configurations RAID avec le compteur Disque logique : Moy. disque, octets/lecture ou Disque logique : Moy. disque, octets/écriture, utilisez les formules répertoriées dans le tableau suivant pour déterminer la vitesse d'entrée et de sortie sur le disque.
| Niveau RAID | Formule |
|---|---|
| RAID 0 | E/S par disque = (lectures + écritures) / nombre de disques |
| RAID 1 | E/S par disque = [lectures + (2 x écritures)] / 2 |
| RAID 5 | E/S par disque = [lectures + (4 x écritures)] / nombre de disques |
| RAID 10 | E/S par disque = [lectures + (2 x écritures)] / nombre de disques |
Supposons que vous disposez d’un système RAID 1 doté de deux disques physiques et que vos compteurs affichent les valeurs indiquées dans le tableau suivant.
| Compteur | Valeur |
|---|---|
| Moyenne disque s/lecture** | 80 |
| Disque logique : moyenne disque s/écriture** | 70 |
| Longueur moyenne de file d'attente du disque** | 5 |
La valeur d’E/S par disque peut être calculée ainsi : (80 + (2 x 70)) /2 = 110
La disk queue length peut être calculée ainsi : 5/2 = 2,5
Cette valeur indique la présence d’un goulot d’étranglement d’E/S en formation.
Autres outils d’analyse
Vous pouvez également surveiller la latence de disque et analyser les tendances à l'aide de la vue de gestion dynamique sys.dm_io_virtual_file_stats disponible dans SQL Server 2008. Pour plus d'informations, reportez-vous à sys.dm_io_virtual_file_stats (Transact-SQL).
SQL Server 2012 pour SharePoint Server 2013
Nous remercions Bill Baer, responsable marketing senior des produits Microsoft, et Brian Alderman, PDG et fondateur de MicroTechPoint, pour la série de modules de formation SQL Server 2012 en ligne qu'ils nous ont fournis. Nous tenons également à remercier tout particulièrement Channel 9 Microsoft qui héberge ces modules de formation en ligne. Les modules suivants fournissent des détails sur les paramètres de base de données SQL Server 2012 et vous aident à comprendre comment améliorer les performances, la disponibilité et la sécurité de SharePoint Server 2016.
Module sur le réglage de SQL Server 2012 pour SharePoint 2013 : partie (03) sur les paramètres de serveur pour SQL Server
Module sur le réglage de SQL Server 2012 pour SharePoint 2013 : partie (04) sur la disponibilité de SQL Server et de SharePoint
Voir aussi
Concepts
Présentation de SQL Server dans des environnements SharePoint Server 2016 et 2019
Optimiser les performances pour SharePoint Server 2013
Meilleures pratiques pour SQL Server dans une batterie de serveurs SharePoint Server
Planification des performances dans SharePoint Server 2013
Gestion et dimensionnement de la capacité pour SharePoint Server 2013
Planification de la capacité pour SharePoint Server 2013
Autres ressources
Présentation de SQL Server dans un environnement SharePoint Server 2013