Meilleures pratiques pour SQL Server dans une batterie de serveurs SharePoint Server

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

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

**Résumé :**Découvrez comment mettre en œuvre les meilleures pratiques pour SQL Server dans une batterie de serveurs SharePoint Server 2016 et SharePoint Server 2013.

Lorsque vous configurez et gérez des bases de données relationnelles SharePoint Server 2016 sur SQL Server 2014 avec Service Pack 1 (SP1) ou SQL Server 2016, vous devez choisir des options qui promeuvent 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.

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 concerne le déploiement de SharePoint Server 2016 avec un rôle de batterie de serveurs à un seul serveur ou SharePoint 2013 sur un serveur autonome, qui est réservé à des opérations de développement ou de test et qu’il n’est pas recommandé d’utiliser pour la production. Pour plus d’informations, reportez-vous à Description de MinRole et des services associés dans SharePoint Server 2016 et Installer SharePoint Server 2016 sur un serveur unique avec SQL Server.

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.

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

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

  Important

  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 :

• Sécurisation de SQL Server

• Configurer la sécurité SQL Server pour SharePoint Server

• Blog sur la sécurisation de SharePoint : renforcement de la sécurité de SQL Server dans les environnements SharePoint

• Centre de sécurité pour le moteur de base de données SQL Server et la base de données SQL Azure

Configurer les serveurs de bases de données pour les performances et la disponibilité

Comme pour les serveurs d’applications et serveurs frontaux, la configuration des serveurs de base de données influe sur les performances de SharePoint Server. Certaines bases de données doivent se trouver sur le même serveur que d’autres, et inversement, certaines bases de données ne peuvent pas se trouver sur le même serveur que d’autres. Pour plus d’informations, voir Description de MinRole et des services associés dans SharePoint Server 2016 et Planification et configuration de la capacité de SQL Server et du stockage (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 est doté de la fonctionnalité de groupes de disponibilité AlwaysOn. 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é AlwaysOn prennent désormais en charge jusqu’à neuf réplicas de disponibilité.

Les groupes de disponibilité AlwaysOn nécessitent un clustering de basculement (WSFC) Windows Server. Un groupe de ressources WSFC est créé pour chaque groupe de disponibilité. Pour plus d’informations, voir les ressources suivantes :

• Groupes de disponibilité AlwaysOn (SQL Server)

• Présentation des groupes de disponibilité AlwaysOn (SQL Server)

• Clustering de basculement et groupes de disponibilité AlwaysOn (SQL Server)

• Configurer des groupes de disponibilité AlwaysOn SQL Server 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.

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

  2. Fichiers journaux de transaction 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 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.

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

  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 de transaction de 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

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 :

  Important

  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.

• Surveiller et régler les performances

• Surveiller et régler les performances

• Analyse des performances et surveillance de l’activité du serveur

• Analyseur de performances Windows

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

See also

Présentation de SQL Server dans un environnement SharePoint Server 2016
Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server)

Sécurisation de SharePoint : renforcer SQL Server dans les environnements SharePoint