Partager via

Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server)

  • Article

 

**Sapplique à :**SharePoint Server 2013, SharePoint Server 2016

**Dernière rubrique modifiée :**2018-02-16

Résumé : Découvrez comment planifier et configurer le niveau de stockage et de base de données pour SQL Server dans SharePoint Server 2016 et SharePoint Server 2013.

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.

Notes

Les tests de performances et de capacité de cet article concernent Microsoft SQL Server 2014 avec Service Pack 1 (SP1), Microsoft SQL Server 2016, SQL Server 2017 RTM et SharePoint Server 2016. Les résultats des tests sont les mêmes que dans SharePoint Server 2013.
Bien qu’aucun test n’ait été effectué sur SQL Server 2014 (SP1), SQL Server 2016 ou SQL Server 2017 RTM, vous pouvez utiliser ces résultats de test pour vous aider à planifier et à configurer le niveau de stockage et de base de données SQL Server dans un environnement SharePoint Server 2016. Pour savoir comment configurer et régler SQL Server 2012, reportez-vous à SQL Server 2012 pour SharePoint Server 2013.

SharePoint Server fonctionnant 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, ce document est destiné à être utilisé à la fois par les responsables de l’implémentation des batteries de serveurs SharePoint Server et par les administrateurs de base de données SQL Server. 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 pour le niveau de stockage et de base de données SharePoint Server 2016

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 :

  1. Identifier les besoins de stockage et d’espace SQL, ainsi que les besoins en matière d’opérations d’E/S

  2. Choisir la version et l’édition de SQL Server

  3. Concevoir l’architecture de stockage en fonction des besoins en capacité et en matière d’opérations d’E/S

  4. Estimer les besoins en mémoire

  5. Comprendre les exigences en matière de topologie du réseau

  6. Configurer SQL Server

  7. Valider la fiabilité et les performances du stockage

Identifier les besoins de stockage et d’espace SQL Server, ainsi que les besoins en matière d’opérations d’E/S

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 :

  • Bases de données utilisées par SharePoint Server

  • 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

  • Déterminer les besoins en matière de stockage et d’IOPS des applications de service

  • Déterminer les besoins en disponibilité

Bases de données utilisées par SharePoint Server

Les bases de données installées avec SharePoint Server 2016 dépendent des applications de service utilisées dans l’environnement. Tous les environnements SharePoint Server 2016 reposent sur les bases de données système SQL Server. Cette section récapitule les bases de données installées avec SharePoint Server 2016. Pour plus d’informations sur les bases de données, voir Types et descriptions des bases de données dans SharePoint Server.

Pour une représentation graphique des bases de données qui prennent en charge SharePoint Server 2016, voir Guide de référence rapide : Bases de données SharePoint Server 2016. Vous pouvez également télécharger cette affiche de base de données SharePoint Server 2016, sous la forme d’un fichier PDF ou Visio.

Notes

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.

Les bases de données suivantes sont les bases de données système SharePoint Server et sont automatiquement installées.

  • Configuration

  • Contenu de l’Administration centrale

  • Contenu (une ou plusieurs)

La liste suivante montre les applications de service SharePoint Server dotées de bases de données :

  • Service de 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

En cas d’intégration plus poussée avec SQL Server, votre environnement peut également inclure des bases de données supplémentaires, 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). Si elle est utilisée, vous devez également préparer la prise en charge de la base de données d’application PowerPivot 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 la prise en charge des deux bases de données SQL Server Reporting Services, ainsi que de la charge supplémentaire nécessaire 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 cours d’utilisation, vous devez prévoir la prise en charge de la base de données d’application PowerPivot et de la charge supplémentaire pour le système. Pour plus d’informations, voir Planifier un déploiement PowerPivot dans une batterie de serveurs SharePoint et l’article SQL Server PRO sur la présentation de PowerPivot et de Power View dans Microsoft Excel 2013.

  • Le plug-in SQL Server 2008 R2 Reporting Services (SSRS) peut être utilisé avec n’importe quel environnement SharePoint 2013. Si vous l’utilisez, prévoyez la prise en charge des deux bases de données SQL Server 2008 R2 Reporting Services, ainsi que de la charge supplémentaire nécessaire pour SQL Server 2008 R2 Reporting Services.

Comprendre SQL Server et les opérations d’E/S par seconde (IOPS)

Sur un serveur hébergeant une instance SQL Server, il est très 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 d’effectuer un test d’évaluation du sous-système d’E/S à l’aide de l’utilitaire Diskspd. Notez que 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 donc de remplacer le mode de récupération complet de la base de données par le mode simple.

Notes

Si vous souhaitez utiliser la mise en miroir de bases de données SQL Server pour assurer une certaine disponibilité à la base de données de configuration, vous devez utiliser le mode de récupération complet.

Les besoins en matière d’IOPS pour la base de données de configuration et la base de données de contenu Administration centrale sont faibles.

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 :

  1. 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

    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.

  2. 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.

  3. 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.

  4. 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 l’évaluons généralement à trois fois le nombre de documents (D), mais cette valeur peut varier en fonction de la façon dont vous prévoyez d’utiliser vos sites.

  5. 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.

Entrée 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)) × 250) + ((10 Ko × (600 000 + (200 000 x 2))) = 110 000 000 Ko ou 105 Go

Notes

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 SharePoint Server suivantes peuvent avoir un impact significatif sur 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

Office Online Server est la nouvelle version d’Office Web Apps Server. L’utilisation de Office Online Server avec SharePoint Server 2016 n’influence 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 Déployer Office Online Server.

Estimer les besoins en matière d’IOPS des bases de données de contenu

Les besoins en matière d’IOPS des bases de données de contenu varient considérablement 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, voir la rubrique Résultats des tests de performances et de capacité, avec recommandations (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 valeur est amplement suffisante et bien supérieure aux besoins de votre environnement. Notez que si vous utilisez la mise en mémoire, vous obtenez beaucoup plus d’E/S qu’avec les bases de données de contenu primaires. Gardez à l’esprit que les bases de données de contenu en miroir sont toujours volumineuses.

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 de toutes les applications de service dans SharePoint Server 2016 sont les mêmes que dans UNRESOLVED_TOKEN_VAL(2nd_OSS_14,) et SharePoint Server 2013.

Besoins en matière de stockage et d’IOPS des applications de service de recherche

Base de données 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 pour 1 DPS

Moyen/élevé

Moyenne

15 Go

Journal de 2 Go

110 Go

Journal de 50 Go

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

Fractionnement si 100 à 300 Go atteints

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.

Notes

Les tests visant à établir les recommandations relatives aux besoins de stockage et aux IOPS des bases de données de profils utilisateur ne sont pas encore terminés. 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 de lui allouer 5 Mo pour 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.

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.

Word Automation Services

L’application de service Word Automation Services 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

L’application de service PerformancePoint Services 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. Notez que les bases de données de contenu ont des besoins en matière d’opérations d’E/S nettement plus élevés que la base de données d’application de service PowerPivot.

Déterminer les besoins en disponibilité

La disponibilité correspond au degré de disponibilité d’un environnement SharePoint Server 2016 d’après les utilisateurs. 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. Voir également le livre blanc SQL Server 2012Guide d’architecture AlwaysOn : mise en place d’une haute disponibilité et de solutions de récupération d’urgence à l’aide des groupes de disponibilité AlwaysOn.

Choisir la version et l’édition de SQL Server

Pour votre environnement, nous vous recommandons, pour SharePoint Server 2016, d’utiliser l’édition Enterprise Edition de SQL Server 2014 avec le Service Pack 1 (SP1) ou SQL Server 2016 ou SQL Server 2017 RTM pour bénéficier des fonctions relatives aux performances, à la disponibilité, à la sécurité et à la gestion offertes par ces versions. Pour plus d’informations sur les avantages de ces versions, consultez les rubriques Fonctionnalités prises en charge par les éditions de SQL Server 2014, Éditions et fonctionnalités prises en charge de SQL Server 2016 et Éditions et fonctionnalités prises en charge de SQL Server 2017.

Pour SharePoint Server 2013, nous vous recommandons d’utiliser l’édition Enterprise Edition de SQL Server 2008 R2 avec Service Pack 1 (SP1), SQL Server 2012 ou SQL Server 2014 pour bénéficier des fonctions relatives aux performances, à la disponibilité, à la sécurité et à la gestion offertes par ces versions. 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, reportez-vous à Compression de sauvegardes (SQL Server) pour SQL Server 2014 et Compression de sauvegardes (SQL Server) pour SQL Server 2016 et SQL Server 2017 RTM.

    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 SQL Server 2014 (SP1), SQL Server 2016 ou SQL Server 2017 RTM Enterprise Edition pour SharePoint Server 2016 et SQL Server 2008 R2 avec SP1 ou SQL Server 2012 Enterprise Edition pour SharePoint Server 2013.

  • 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 du gouverneur de ressources, voir Gouverneur de ressources pour SQL Server 2014 et Gouverneur de ressources pour SQL Server 2016.

    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 PowerPivot pour SharePoint  Permet aux utilisateurs de partager et de collaborer sur des modèles de données générés par l’utilisateur et des analyses dans Excel Online tout en actualisant automatiquement ces analyses. Vous devez disposer d’Office Online pour utiliser Excel Online avec PowerPivot 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 UNRESOLVED_TOKEN_VAL(sql-2014-2ème) (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

  • Choisir des types de disque

  • Choisir des types RAID

Choisir une architecture de stockage

SharePoint Server prend en charge les architectures de stockage à connexion directe (DAS, Direct Attached Storage), de réseau de zone de stockage (SAN, Storage Area Network) et de stockage connecté au réseau (NAS, Network Attached Storage). L’architecture NAS n’est toutefois prise en charge qu’avec les bases de données de contenu configurées pour utiliser le stockage BLOB distant. Le choix dépend de facteurs inhérents à votre solution d’entreprise et à l’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)

Le SAN est une architecture permettant de connecter des dispositifs de stockage d’ordinateur distants (comme des baies de disques et des bibliothèques de bandes) à des serveurs de sorte qu’ils semblent connectés localement au système d’exploitation (stockage de bloc par exemple).

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é sont les suivants :

  • 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

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.
Une certaine confusion existe au sujet du protocole NAS si vous utilisez un stockage iSCSI (Internet Small Computer System Interface). Si vous accédez au stockage iSCSI via CIFS (Common Internet File System), nous sommes dans le cas d’un protocole NAS. Autrement dit, vous ne pouvez pas utiliser ce stockage avec des bases de données de contenu si celles-ci ne sont pas configurées pour utiliser le stockage BLOB distant. Toutefois, si vous accédez au stockage iSCSI via un disque dur connecté localement, nous sommes dans le cas d’une architecture SAN et l’utilisation avec le NAS est possible.

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

    Pour plus d’informations sur l’utilisation des disques SSD pour le stockage dans SQL Server, voir l’article de SQL Server PRO sur l’utilisation des disques SSD dans les solutions de stockage SQL Server.

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

Au-delà de 64 Go, la RAM supplémentaire permet d’améliorer la vitesse de mise en cache de SQL Server.

Notes

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 requise pour SQL Server, voir Configurations matérielle et logicielle requises pour l’installation de SQL Server 2014 et Configurations matérielle et logicielle requises pour l’installation de SQL Server 2016.

Pour plus d’informations sur les spécifications et les limites de capacité de SQL Server, voir Limites de capacité de calcul par l’édition de SQL Server et Spécifications des capacités maximales pour SQL Server.

Les facteurs suivants sont également susceptibles d’avoir un impact sur 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 approprié si vous envisagez d’utiliser la suite d’implémentation SQL Server AlwaysOn, la mise en miroir, la copie de journaux ou le clustering de basculement pour tenir à jour un site distant.

  • 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 :

  • Déterminer le nombre d’instances ou de serveurs nécessaires

  • Configurer le stockage et la mémoire

  • Définir les options SQL Server

  • Configurer les bases de données

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 indications suivantes concernent le moment auquel déployer un serveur supplémentaire exécutant une instance SQL Server :

  • Ajoutez un serveur de base de données supplémentaire lorsque vous avez plus de quatre serveurs web s’exécutant à pleine capacité.

  • Ajoutez un serveur de base de données supplémentaire si votre serveur actuel a atteint ses limites effectives en matière de ressources de RAM, de processeur, de débit d’E/S de disque, de capacité de disque ou de débit de 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 la création automatique de statistiques sur un serveur hébergeant SQL Server et prenant 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 avoir un impact considérable sur 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 d’utilisation, les bases de données de recherche et les journaux de transactions SQL Server 2014 (SP1), SQL Server 2016, SQL Server 2017 RTM et SQL Server 2008 R2 avec SP1 et SQL Server 2012 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 :

    1. Fichiers de données tempdb et journaux de transactions

    2. Fichiers journaux des transactions de base de données

    3. Bases de données de recherche, à l’exception de la base de données d’administration de recherche

    4. 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 données des tests et des clients montrent que les performances des batteries de serveurs SharePoint Server peuvent être considérablement ralenties si les E/S de disque sont 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 une matrice RAID 10. Le nombre de fichiers de données tempdb doit être égal au nombre de processeurs et les fichiers de données tempdb doivent être définis sur une taille équivalente. À cet effet, comptez chaque processeur double cœur comme deux processeurs et chaque processeur prenant en charge l’hyperthreading comme un seul processeur. Pour plus d’informations, voir Optimisation des performances de la base de données 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. À cet effet, comptez chaque processeur double cœur comme deux processeurs et chaque processeur prenant en charge l’hyperthreading comme un seul processeur.

  • Créez des fichiers de données de taille équivalente.

Important

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 la taille maximale des bases de données de contenu, voir la section « Limites des bases de données de contenu » dans Limitations et frontières logicielles pour SharePoint Server 2016.

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. Cette action réduit la fréquence à laquelle SQL Server augmente la taille des fichiers. L’augmentation de la taille d’un fichier est une action bloquante qui suppose de remplir le nouvel espace par des pages vides.

    • S’il n’est pas prévu que la taille calculée de la base de données de contenu atteigne la taille maximale recommandée (200 Go) au cours de l’année à venir, définissez-la sur la taille maximale que la base de données devrait atteindre en un an, avec une marge d’erreur supplémentaire de 20 %, en utilisant 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 les rubriques Surveiller et régler les performances pour SQL Server 2014 (SP1) et Surveiller et régler les performances pour SQL Server 2016 et SQL Server 2017 RTM.

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 :

  • Statistiques générales Cet objet fournit des compteurs pour surveiller l’activité générale de l’ensemble du serveur, comme le nombre de connexions en cours et le nombre d’utilisateurs se connectant et se déconnectant, par seconde, à partir d’ordinateurs exécutant une instance de SQL Server. Pensez à surveiller le compteur suivant :

    • 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. Cette valeur ne doit pas dépasser 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, déterminez s’il existe une activité de processus anormale ou si le serveur a besoin de processeurs supplémentaires.

  • 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 :

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. Notez que les valeurs suivantes représentent des valeurs mesurées dans le temps et non des valeurs correspondant à des pics d’activité soudains ou basées sur une seule mesure.

  • Disque physique : Pourcentage du temps disque : lecteur de données Ce compteur indique le pourcentage de temps écoulé que le lecteur de disque sélectionné consacre à traiter les demandes de lecture ou d’écriture. Il donne une indication générale sur le taux d’occupation du disque. Si la valeur du compteur Disque physique : Pourcentage du temps disque est élevée (plus de 90 %), vérifiez le compteur Disque physique : Taille de file d’attente du disque actuelle pour savoir combien de demandes système sont en attente d’un accès au disque. Le nombre de demandes d’E/S en attente doit être maintenu à moins de 1,5 à 2 fois le nombre de piles composant 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. Cela signifie qu’une valeur inférieure ou égale à 8 peut être acceptable pour une unité logique composée de 4 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 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 d’échantillonnage. La règle est qu’il doit y avoir au plus deux demandes de lecture et d’écriture en attente par pile, mais cela peut s’avérer difficile à mesurer en raison de la virtualisation du stockage et des différences de niveaux RAID entre les configurations. Recherchez s’il existe à la fois des longueurs de file d’attente du disque supérieures à la moyenne et des latences de disque supérieures à la moyenne. Si tel est le cas, il est possible que le cache du groupe de stockage soit surutilisé ou que le partage des piles 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, voir la page sur l’utilitaire Diskspd, un outil de tests de stockage fiable (remplaçant SQLIO).

    • Disque logique : Moyenne disque s/lecture Ce compteur indique le temps moyen, en secondes, d’une opération de lecture à partir du disque. Sur un système correctement configuré, les valeurs idéales sont comprises entre 1 et 5 millisecondes (ms) pour les journaux (idéalement 1 ms sur une matrice mise en cache) et entre 4 et 20 ms pour les données (idéalement moins de 10 ms). Des latences élevées peuvent se produire pendant les périodes de pointe, mais si vous constatez des valeurs élevées régulièrement, vous devez déterminer leur cause.

    • Disque logique : Moyenne disque s/écriture Ce compteur indique le temps moyen, en secondes, d’une opération d’écriture sur le disque. Sur un système correctement configuré, les valeurs idéales sont comprises entre 1 et 5 ms pour les journaux (idéalement 1 ms sur une matrice mise en cache) et entre 4 et 20 ms pour les données (idéalement moins de 10 ms). Des latences élevées peuvent se produire pendant les périodes de pointe, mais si vous constatez des valeurs élevées régulièrement, vous devez déterminer leur 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 × écritures)] / 2

    RAID 5

    E/S par disque = [lectures + (4 × écritures)] / nombre de disques

    RAID 10

    E/S par disque = [lectures + (2 × é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 comme suit : (80 + (2 × 70)) / 2 = 110

    La taille de file d’attente du disque peut être calculée comme suit : 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.

See also

Présentation de SQL Server dans un environnement SharePoint Server 2016
Optimiser les performances pour SharePoint Server 2013
Meilleures pratiques pour SQL Server dans une batterie de serveurs SharePoint Server
Planifier les performances de planification dans Microsoft SharePoint Server 2013
Gestion et dimensionnement de la capacité pour SharePoint Server 2013
Planification de la capacité pour SharePoint Server 2013

Présentation de SQL Server dans un environnement SharePoint Server 2013