Meilleures pratiques pour SQL Server dans une batterie de serveurs SharePoint Server
S’APPLIQUE À :
2013 2016 2019 Édition d’abonnement 
SharePoint dans Microsoft 365
Lorsque vous configurez et gérez des bases de données relationnelles SharePoint Server 2016 et 2019 sur SQL Server 2014 avec Service Pack 1 (SP1), SQL Server 2016 ou SQL Server 2017 RTM, vous devez choisir des options qui favorisent les performances et la sécurité. De même, vous devez choisir des options qui promeuvent les performances et la sécurité lorsque vous configurez et gérez des bases de données relationnelles SharePoint Server 2013 sur SQL Server 2008 R2 avec Service Pack 1 (SP1), SQL Server 2012 et SQL Server 2014.
Les meilleures pratiques décrites dans cet article sont indiquées en fonction de l'ordre dans lequel elles s'appliqueraient, de l'installation et de la configuration de SQL Server, au déploiement de SharePoint Server et à la maintenance de la batterie de serveurs. La plupart des pratiques s'appliquent aux deux versions de SQL Server. Les pratiques propres à l'une ou l'autre des versions de SQL Server font l'objet de sections distinctes.
Notes
[!REMARQUE] Si vous comptez utiliser des composants Business Intelligence de SQL Server dans une batterie de serveurs SharePoint Server 2016, vous devez utiliser SQL Server 2016 CTP 3.1 ou une version ultérieure. Vous pouvez désormais télécharger SQL Server 2016 CTP 3.1 ou version ultérieure pour utiliser le complément SQL Server PowerPivot pour SharePoint. Vous pouvez aussi utiliser Power View en installant SQL Server Reporting Services (SSRS) en mode intégré SharePoint et le complément frontal SSRS à partir du support d'installation de SQL Server.
Pour plus d'informations, téléchargez le nouveau livre blanc relatif au déploiement de SQL Server 2016 Power Pivot et Power View 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.
Notes
[!REMARQUE] Si vous planifiez d'utiliser les composants d'aide à la décision de SQL Server dans une batterie de serveurs SharePoint Server 2013, vous devez utiliser SQL Server 2012 avec Service Pack 1 (SP1) ou SQL Server 2014. Pour plus d'informations sur l'aide à la décision SQL Server 2012 avec SP1 et SharePoint Server 2013, reportez-vous à Installer des fonctionnalités SQL Server BI avec SharePoint 2013 (SQL Server 2012 SP1). Pour plus d'informations sur SQL Server 2014 et SharePoint Server 2013, reportez-vous à Installer les fonctionnalités Business Intelligence de SQL Server 2014.
Importante
Les meilleures pratiques décrites dans cet article s'appliquent au système de gestion de base de données relationnelle (SGBDR) de SQL Server avec SharePoint Server.
Utiliser un serveur dédié pour SQL Server
Pour bénéficier de performances optimales pour les opérations de batterie de serveurs, nous vous conseillons d'installer SQL Server sur un serveur dédié qui n'exécute pas d'autres rôles de batterie de serveurs et n'héberge pas de bases de données pour d'autres applications. La seule exception est le déploiement de SharePoint Server 2016 ou 2019 dans un rôle de batterie de Single-Server ou SharePoint 2013 sur un serveur autonome, qui est destiné au développement ou au test et n’est pas recommandé pour une utilisation en production. Pour plus d’informations, voir Description de MinRole et des services associés dans SharePoint Server 2016 et 2019 et Installer SharePoint Server 2016 ou 2019 sur un serveur.
Notes
La recommandation portant sur le recours à un serveur dédié pour les bases de données relationnelles s'applique également au déploiement de SQL Server dans des environnements virtuels.
Configurer des paramètres SQL Server spécifiques avant de déployer SharePoint Server
Pour garantir un comportement et des performances cohérents, configurez les options et les paramètres suivants avant de déployer SharePoint Server.
En raison de problèmes de performances potentiels liés à la maintenance de plusieurs instances SQL, nous vous recommandons d’utiliser une seule instance de SQL Server par serveur de base de données déployé.
N'activez pas la création automatique de statistiques sur des bases de données de contenu SharePoint. Cette opération n'est pas prise en charge pour SharePoint Server. SharePoint Server configure les paramètres requis lors de l'approvisionnement et de la mise à niveau. L'activation manuelle de la création automatique de statistiques sur une base de données SharePoint peut radicalement modifier le plan d'exécution d'une requête. Les bases de données SharePoint utilisent une procédure stockée qui conserve les statistiques (proc_UpdateStatistics) ou invoquent SQL Server.
Pour SharePoint Server 2013, les plans de maintenance sont gérés par SharePoint :
- Les statistiques SQL sont gérées par la règle d’intégrité « Les bases de données utilisées par SharePoint ont des statistiques d’index obsolètes » qui appelle proc_updatestatics
- La propriété Mise à jour automatique des statistiques des bases de données de contenu est définie sur False
Pour SharePoint Server 2016 et 2019, l’administrateur SQL doit créer des plans de maintenance pour les bases de données de contenu SharePoint :
- Les statistiques SQL ne sont pas gérées par la règle d’intégrité « Les bases de données utilisées par SharePoint ont des statistiques d’index obsolètes »
- La propriété Statistiques de mise à jour automatique des bases de données de contenu est définie sur True `
Définissez le degré maximal de parallélisme (MAXDOP) sur 1 pour les instances de SQL Server qui hébergent des bases de données SharePoint afin qu'un seul processus SQL Server soit associé à chaque demande.
Importante
L'attribution d'une autre valeur au degré maximal de parallélisme peut entraîner l'utilisation d'un plan de requête moins adapté, ce qui réduirait les performances de SharePoint Server.
Pour simplifier la maintenance, comme pour faciliter le déplacement des bases de données vers un autre serveur, créez des alias DNS pointant vers l'adresse IP de toutes les instances de SQL Server. Pour plus d'informations sur les alias DNS ou de nom d'hôte, voir le billet de blog sur l'ajout d'un alias de nom d'hôte à une instance SQL Server.
Pour plus d'informations sur ces paramètres et options SQL Server, voir Définir les options SQL Server.
Consolider le serveur de base de données avant de déployer SharePoint Server
Nous vous recommandons de planifier le serveur de base de données et de le consolider avant de déployer SharePoint Server. Pour plus d'informations, voir :
Configurer les serveurs de bases de données pour les performances et la disponibilité
Comme pour les serveurs frontaux et les serveurs d’applications, la configuration des serveurs de base de données affecte les performances de SharePoint Server. Certaines bases de données doivent se trouver sur le même serveur que d’autres bases de données. À l’inverse, certaines bases de données ne peuvent pas se trouver sur le même serveur que d’autres bases de données. Pour plus d’informations, voir Description de MinRole et des services associés dans SharePoint Server 2016 et 2019 et Planification et configuration de la capacité stockage et SQL Server (SharePoint Server).
Pour obtenir des conseils sur les bases de données hautement disponibles utilisant la mise en miroir, voir Mise en miroir de bases de données (SQL Server).
Clustering de basculement et groupes de disponibilité AlwaysOn dans SQL Server
SQL Server 2012 a introduit la fonctionnalité Groupes de disponibilité Always On. Cette fonctionnalité est une solution de haute disponibilité et de récupération d’urgence qui peut se substituer à la mise en miroir de bases de données et l’envoi de journaux. Les groupes de disponibilité Always On prennent désormais en charge jusqu’à neuf réplicas de disponibilité.
Notes
[!REMARQUE] La mise en miroir de bases de données sera abandonnée dans les versions futures de SQL Server. Nous vous recommandons de toujours utiliser les groupes de disponibilité AlwaysOn.
Les groupes de disponibilité Always On nécessitent un cluster WSFC (Windows Server Failover Clustering). Un groupe de ressources WSFC est créé pour chaque groupe de disponibilité. Pour plus d’informations, consultez les ressources suivantes :
Vue d’ensemble des groupes de disponibilité Always On (SQL Server)
Clustering de basculement et groupes de disponibilité AlwaysOn (SQL Server)
Configurer des groupes de disponibilité SQL Server Always On pour SharePoint Server
Concevoir un stockage pour un débit et une simplicité de gestion optimaux
Nous vous recommandons de séparer et de hiérarchiser vos données entre les lecteurs sur le serveur de base de données. 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 sur des disques durs physiques distincts. La liste suivante prodigue quelques conseils. Pour plus d’informations, voir Configurer des bases de données.
Pour les sites de collaboration ou mis à jour fréquemment, utilisez l’ordre de distribution de stockage suivant.
L'élément le plus haut placé doit être situé sur les lecteurs les plus rapides.
Rank Élément 1 Fichiers de données tempdb et journaux des transactions 2 Fichiers journaux des transactions de la base de données de contenu 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 de contenu Pour un site portail largement destiné à la lecture, donnez la priorité aux données et à la recherche par rapport aux journaux de transaction, comme suit.
L'élément le plus haut placé doit être situé sur les lecteurs les plus rapides.
Rank Élément 1 Fichiers de données tempdb et journaux des transactions 2 Fichiers de données de base de données de contenu 3 Bases de données de recherche, à l’exception de la base de données d’administration de recherche 4 Fichiers journaux des transactions de la base de données de contenu Le test et les données utilisateur indiquent que des E/S disque insuffisantes pour la base de données tempdb peuvent considérablement entraver les performances globales de la batterie de serveurs. Pour éviter ce problème, allouez des disques dédiés au lecteur stockant les fichiers de données tempdb.
Pour optimiser les performances, utilisez un dispositif RAID 10 pour le lecteur stockant les fichiers de données tempdb. Le nombre de fichiers de données tempdb doit correspondre au nombre de cœurs de processeur, et tous les fichiers de données tempdb doivent avoir la même taille.
Placez les données de base de données et les fichiers journaux de transaction sur des disques distincts. Si les données et les fichiers journaux doivent partager des disques faute d’espace, placez les fichiers avec des modèles d’utilisation différents sur le même disque pour limiter les demandes d’accès simultanées.
Utilisez plusieurs fichiers de données pour les bases de données de contenu à forte utilisation, et placez chacune d’elles sur un disque qui lui est propre.
Pour faciliter la gestion, surveillez les bases de données de contenu et procédez aux ajustements nécessaires pour qu’elles ne dépassent pas 200 Go, au lieu de limiter leur taille.
Notes
Si vous limitez manuellement la taille des bases de données SQL Server, vous risquez de créer un temps mort inattendu dans le système lorsque la capacité est dépassée.
Une bonne configuration des sous-systèmes d'E/S est très importante pour des performances et une utilisation optimales des systèmes SQL Server. Pour plus d'informations, voir l'article sur la surveillance de l'utilisation du disque
Conseil
Sachez que la vitesse de disque se mesure différemment pour les fichiers de données et les fichiers journaux. Les lecteurs les plus rapides pour les données de base de données peuvent ne pas être les plus rapides pour les fichiers journaux. Tenez compte des modèles d’utilisation, des E/S et de la taille de fichier.
Gérer de manière proactive la croissance des fichiers de données et des fichiers journaux
Les recommandations suivantes permettent de gérer de manière proactive la croissance des fichiers de données et des fichiers journaux :
Dans la mesure du possible, augmentez la taille de tous les fichiers de données et fichiers journaux jusqu’à atteindre la taille finale prévue, ou augmentez-la à intervalles réguliers (par exemple, tous les mois ou tous les six mois) ou avant le déploiement d’un nouveau site à stockage intensif, comme pendant la migration de fichiers.
Activez la croissance automatique de base de données pour veiller à ne pas manquer d’espace dans les fichiers de données et dans les fichiers journaux. Vous devez tenir compte des éléments suivants :
Importante
Vous devez prendre en compte les problèmes de performances et d'utilisation associés à la croissance automatique. Pour plus d'informations, voir la rubrique relative aux points à prendre en compte pour les paramètres de croissance/réduction automatique dans SQL Server.
Les paramètres par défaut d'une nouvelle base de données définissent une croissance par incréments de 1 Mo. Étant donné que cette valeur entraîne une augmentation de la taille de la base de données, ne vous fiez pas au paramètre par défaut. Suivez plutôt les instructions fournies à la rubrique relative à la définition des options SQL Server.
Attribuez aux valeurs de croissance automatique un nombre fixe de mégaoctets plutôt qu’un pourcentage. Plus la base de données est volumineuse, plus la croissance devrait être importante.
Notes
Faites attention lorsque vous définissez la fonctionnalité de croissance automatique pour les bases de données SharePoint. Si vous attribuez un pourcentage à la croissance automatique d’une base de données (par exemple, un taux de croissance de 10 %), une base de données de 5 Go augmente de 500 Mo à chaque fois qu’un fichier de données est étendu. Dans ce scénario, vous pourriez manquer d’espace disque.
Prenons par exemple un scénario dans lequel le contenu augmente progressivement, disons par incréments de 100 Mo, et dans lequel la croissance automatique est définie sur 10 Mo. Un site de gestion de documents a subitement besoin d’un très grand volume de stockage de données, avec éventuellement une taille initiale de 50 Go. Pour cet ajout important, une croissance par incréments de 500 Mo est plus adaptée que des incréments de 100 Mo.
Dans un système de production géré, considérez la croissance automatique comme une simple voie de secours en cas de croissance inattendue. N’utilisez pas cette option pour gérer la croissance de vos données et de vos journaux au quotidien. En revanche, définissez la croissance automatique de manière à autoriser une taille approximative sur un an, puis ajoutez une marge d’erreur de 20 %. Définissez également une alerte pour être averti lorsque la base de données manque d’espace ou approche de la taille maximale.
Maintenez un niveau d’espace disque disponible d’au moins 25 % sur les lecteurs pour gérer la croissance et les modèles de pics d’utilisation. Si vous ajoutez des lecteurs à un tableau RAID ou allouez davantage d’espace à gérer, surveillez étroitement la capacité pour éviter le manque d’espace.
Surveiller en permanence le stockage et les performances de SQL Server
Nous vous conseillons de surveiller en permanence le stockage et les performances de SQL Server pour vous assurer que chaque serveur de base de données de production gère correctement sa charge. En outre, une surveillance permanente vous permet d'établir des références qui vous serviront pour la planification des ressources.
Considérez la surveillance des ressources dans son ensemble. Ne la limitez pas aux ressources propres à SQL Server. Il est tout aussi important de suivre les ressources suivantes sur les ordinateurs exécutant SQL Server : processeur, mémoire, taux d'accès au cache et sous-système d'E/S.
Lorsque des ressources serveur semblent lentes ou surchargées, tenez compte des instructions suivantes en matière de performances et basées sur la charge de travail en cours et prévue.
Utiliser la compression de sauvegarde pour accélérer les sauvegardes et réduire la taille des fichiers
La compression de sauvegardes peut accélérer les opérations de sauvegarde de SharePoint. Elle est disponible dans SQL Server Standard Edition et Enterprise Edition. Si vous définissez l'option de compression dans votre script de sauvegarde ou que vous configurez SQL Server pour effectuer une compression par défaut, vous pouvez réduire considérablement la taille de vos sauvegardes de base de données et de vos journaux expédiés. Pour plus d'informations, reportez-vous à Compression de sauvegardes (SQL Server) et Compression de données, ou Activer la compression sur une table ou un index
Remerciements
Pour cet article, l'équipe de publication de contenu SharePoint Server remercie les contributeurs suivants :
Kay Unkroth, responsable projet, SQL Server
Chuck Heinzelman, responsable projet, SQL Server
Voir aussi
Concepts
Présentation de SQL Server dans des environnements SharePoint Server 2016 et 2019
Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server)
Autres ressources
Sécurisation de SharePoint : renforcer SQL Server dans les environnements SharePoint