Performances médiocres de SQL Server 2016 Enterprise

Désolé d'être long, mais je veux vous donner autant d'informations que possible afin que cela puisse être utile à l'analyse.

Je sais qu'il y a plusieurs messages avec des problèmes similaires, cependant, j'ai déjà suivi ces différents messages et autres informations disponibles sur le Web, mais le problème persiste.

J'ai un grave problème de performances dans SQL Server qui rend les utilisateurs fous. Ce problème se prolonge depuis plusieurs années, et jusqu'à la fin de 2016 a été géré par une autre entité et à partir de 2017 est venu à être géré par moi.

Au milieu de 2017, j'ai pu résoudre le problème en suivant les conseils d'indexation indiqués par les rapports du tableau de bord des performances de Microsoft SQL Server 2012. L'effet était immédiat, cela sonnait comme par magie. Le processeur qui était dans les derniers jours presque toujours à 100%, est devenu super serein et les retours des utilisateurs ont été retentissants. Même notre technicien ERP était ravi, car il fallait généralement 20 minutes pour obtenir certaines listes et, finalement, il pouvait le faire en quelques secondes.

Au fil du temps, cependant, elle a lentement commencé à empirer. J'ai évité de créer plus d'index, de peur qu'un trop grand nombre d'index n'aggrave les performances. Mais à un moment donné, j'ai dû effacer ceux qui n'avaient pas d'utilité et créer les nouveaux que Performance Dashboard me suggère. Mais pas d'impact.

La lenteur ressentie se fait essentiellement lors de l'épargne et du conseil, dans l'ERP.

J'ai un Windows Server 2012 R2 dédié à SQL Server 2016 Enterprise (64 bits) avec la configuration suivante:

• Processeur: Intel Xeon CPU E5-2650 v3 @ 2,30 GHz
• Mémoire: 84 Go
• En termes de stockage, le serveur dispose d'un volume dédié au système d'exploitation, un autre dédié aux données et un autre dédié aux logs.
• 17 bases de données
• Utilisateurs:
  • Dans la plus grande base de données sont connectés plus ou moins 113 utilisateurs simultanés
  • Dans un autre, il y a environ 9 utilisateurs
  • Dans deux d'entre eux sont 3 + 3
  • Les autres n'ont qu'un seul utilisateur chacun
  • Nous avons un site Web qui écrit également pour la plus grande base de données, mais où l'utilisation est beaucoup moins régulière et qui devrait compter environ 20 utilisateurs.
• Taille des DB:
  • La plus grande des bases de données a 290 Go
  • Le deuxième plus grand a 100 Go
  • Le troisième plus grand a 20 Go
  • Le quatrième 14 Go
  • Le reste fait un peu plus de 3 Go chacun

Il s'agit de l'instance de production, mais nous avons également une instance de développement qui, je crois, peut être ignorée à cet effet, car la plupart du temps je suis le seul à y connecter, mais ce problème se produit constamment, même lorsque je ne suis pas connecté .

Le processeur est presque toujours comme ça:

Nous avons des routines qui fonctionnent pendant la nuit (pas problématique) et certaines qui fonctionnent pendant la journée.

Les utilisateurs se connectent via Remote Desktop à d'autres ordinateurs configurés par ODBC 32 pour accéder à SQL Server.

Le Datacenter où se trouvent les serveurs a 100/100 Mbps, ainsi que là où je suis. La plupart des sites sont liés par MPLS et d'autres par IPSec (de FO à 4G). Le fournisseur a fait de nombreuses analyses et le circuit est ok.

Le taux de réussite du cache est de 99% (à la fois les demandes des utilisateurs et les sessions des utilisateurs)

Les attentes ressemblent à ceci:

J'ai déjà collecté des données avec Perfmon et j'ai les résultats si cela peut aider votre analyse - personnellement, je n'ai tiré aucune conclusion de l'analyse.

Je compte sur votre soutien pour résoudre ce problème, étant disponible pour fournir les informations que vous jugez nécessaires à la résolution.

Merci beaucoup.

Voici la démarque sp_blitz (j'ai remplacé les noms d'entreprises par des pseudonymes):

Priorité 1: fiabilité :

• Dernier bon DBCC CHECKDB de plus de 2 semaines

  • Maître

  • modèle - Dernier succès CHECKDB: 2018-02-07 15: 04: 26.560

  • msdb - Dernière vérification réussie: 2018-02-07 15: 04: 27.740

Priorité 10: Performance :

• CPU avec nombre impair de cœurs

  • Le nœud 0 a 5 cœurs affectés. C'est une configuration NUMA vraiment mauvaise.

  • Le nœud 1 a 5 cœurs affectés. C'est une configuration NUMA vraiment mauvaise.

Priorité 20: Configuration des fichiers :

• TempDB sur le lecteur C tempdb - La base de données tempdb contient des fichiers sur le lecteur C. TempDB croît fréquemment de façon imprévisible, ce qui expose votre serveur au risque de manquer d'espace disque C et de se bloquer brutalement. C est également souvent beaucoup plus lent que les autres disques, les performances peuvent donc en souffrir.

Priorité 50: Fiabilité :

• Erreurs enregistrées récemment dans la trace par défaut
  • master - 2018-03-07 08: 43: 11.72 Erreur de connexion: 17892, gravité: 20, état: 1. 2018-03-07 08: 43: 11.72 La connexion a échoué pour la connexion 'example_user' en raison du déclenchement de l'exécution. [CLIENT: IPADDR]

(Remarque: de nombreuses erreurs comme celle-ci sont dues à un déclencheur activé qui limite les sessions utilisateur - pour le contrôle de l'utilisation des licences ERP)

• Vérification de page non optimale

  • DATABASE_A - La base de données [DATABASE_A] n'a AUCUN pour la vérification de page. SQL Server peut avoir plus de difficulté à reconnaître et à récupérer d'une corruption de stockage. Envisagez plutôt d'utiliser CHECKSUM.

  • DATABASE_B - La base de données [DATABASE_B] n'a AUCUN pour la vérification de page. SQL Server peut avoir plus de difficulté à reconnaître et à récupérer d'une corruption de stockage. Envisagez plutôt d'utiliser CHECKSUM.

  • DATABASE_C - La base de données [DATABASE_C] n'a AUCUN pour la vérification de page. SQL Server peut avoir plus de difficulté à reconnaître et à récupérer d'une corruption de stockage. Envisagez plutôt d'utiliser CHECKSUM.

  • DATABASE_D - La base de données [DATABASE_D] n'a AUCUN pour la vérification de page. SQL Server peut avoir plus de difficulté à reconnaître et à récupérer d'une corruption de stockage. Envisagez plutôt d'utiliser CHECKSUM.

  • DATABASE_E - La base de données [DATABASE_E] n'a AUCUN pour la vérification de page. SQL Server peut avoir plus de difficulté à reconnaître et à récupérer d'une corruption de stockage. Envisagez plutôt d'utiliser CHECKSUM.

  • DATABASE_F - La base de données [DATABASE_F] n'a AUCUN pour la vérification de page. SQL Server peut avoir plus de difficulté à reconnaître et à récupérer d'une corruption de stockage. Envisagez plutôt d'utiliser CHECKSUM.

  • DATABASE_G - La base de données [DATABASE_G] n'a AUCUN pour la vérification de page. SQL Server peut avoir plus de difficulté à reconnaître et à récupérer d'une corruption de stockage. Envisagez plutôt d'utiliser CHECKSUM.

  • DATABASE_H - La base de données [DATABASE_H] n'a AUCUN pour la vérification de page. SQL Server peut avoir plus de difficulté à reconnaître et à récupérer d'une corruption de stockage. Envisagez plutôt d'utiliser CHECKSUM.

  • DATABASE_I - La base de données [DATABASE_I] n'a AUCUN pour la vérification de page. SQL Server peut avoir plus de difficulté à reconnaître et à récupérer d'une corruption de stockage. Envisagez plutôt d'utiliser CHECKSUM.

  • DATABASE_Z - La base de données [DATABASE_Z] n'a AUCUN pour la vérification de page. SQL Server peut avoir plus de difficulté à reconnaître et à récupérer d'une corruption de stockage. Envisagez plutôt d'utiliser CHECKSUM.

  • DATABASE_K - La base de données [DATABASE_K] n'a AUCUN pour la vérification de page. SQL Server peut avoir plus de difficulté à reconnaître et à récupérer d'une corruption de stockage. Envisagez plutôt d'utiliser CHECKSUM.

  • DATABASE_J - La base de données [DATABASE_J] n'a AUCUN pour la vérification de page. SQL Server peut avoir plus de difficulté à reconnaître et à récupérer d'une corruption de stockage. Envisagez plutôt d'utiliser CHECKSUM.

  • DATABASE_L - La base de données [DATABASE_L] n'a AUCUN pour la vérification de page. SQL Server peut avoir plus de difficulté à reconnaître et à récupérer d'une corruption de stockage. Envisagez plutôt d'utiliser CHECKSUM.

  • DATABASE_M - La base de données [DATABASE_M] n'a AUCUN pour la vérification de page. SQL Server peut avoir plus de difficulté à reconnaître et à récupérer d'une corruption de stockage. Envisagez plutôt d'utiliser CHECKSUM.

  • DATABASE_O - La base de données [DATABASE_O] n'a AUCUN pour la vérification de page. SQL Server peut avoir plus de difficulté à reconnaître et à récupérer d'une corruption de stockage. Envisagez plutôt d'utiliser CHECKSUM.

  • DATABASE_P - La base de données [DATABASE_P] n'a AUCUN pour la vérification de page. SQL Server peut avoir plus de difficulté à reconnaître et à récupérer d'une corruption de stockage. Envisagez plutôt d'utiliser CHECKSUM.

  • DATABASE_Q - La base de données [DATABASE_Q] n'a AUCUN pour la vérification de page. SQL Server peut avoir plus de difficulté à reconnaître et à récupérer d'une corruption de stockage. Envisagez plutôt d'utiliser CHECKSUM.

  • DATABASE_R - La base de données [DATABASE_R] n'a AUCUN pour la vérification de page. SQL Server peut avoir plus de difficulté à reconnaître et à récupérer d'une corruption de stockage. Envisagez plutôt d'utiliser CHECKSUM.

  • DATABASE_S - La base de données [DATABASE_S] n'a AUCUN pour la vérification de page. SQL Server peut avoir plus de difficulté à reconnaître et à récupérer d'une corruption de stockage. Envisagez plutôt d'utiliser CHECKSUM.

  • DATABASE_T - La base de données [DATABASE_T] n'a AUCUN pour la vérification de page. SQL Server peut avoir plus de difficulté à reconnaître et à récupérer d'une corruption de stockage. Envisagez plutôt d'utiliser CHECKSUM.

  • DATABASE_U - La base de données [DATABASE_U] n'a AUCUN pour la vérification de page. SQL Server peut avoir plus de difficulté à reconnaître et à récupérer d'une corruption de stockage. Envisagez plutôt d'utiliser CHECKSUM.

  • DATABASE_V - La base de données [DATABASE_V] n'a AUCUN pour la vérification de page. SQL Server peut avoir plus de difficulté à reconnaître et à récupérer d'une corruption de stockage. Envisagez plutôt d'utiliser CHECKSUM.

  • DATABASE_X - La base de données [DATABASE_X] n'a AUCUN pour la vérification de page. SQL Server peut avoir plus de difficulté à reconnaître et à récupérer d'une corruption de stockage. Envisagez plutôt d'utiliser CHECKSUM.

• DAC distant désactivé - L'accès à distance à la connexion d'administration dédiée (DAC) n'est pas activé. Le DAC peut faciliter le dépannage à distance lorsque SQL Server ne répond pas.

Priorité 50: Informations sur le serveur :

• Initialisation instantanée des fichiers non activée - Envisagez d'activer IFI pour des restaurations plus rapides et des croissances de fichiers de données.

Priorité 100: Performance :

• Facteur de remplissage modifié

  • DATABASE_A - La base de données [DATABASE_A] contient 417 objets avec un facteur de remplissage = 70%. Cela peut entraîner des problèmes de performances de mémoire et de stockage, mais peut également empêcher les fractionnements de page.

  • DATABASE_B - La base de données [DATABASE_B] contient 318 objets avec un facteur de remplissage = 70%. Cela peut entraîner des problèmes de performances de mémoire et de stockage, mais peut également empêcher les fractionnements de page.

  • DATABASE_C - La base de données [DATABASE_C] contient 346 objets avec un facteur de remplissage = 70%. Cela peut entraîner des problèmes de performances de mémoire et de stockage, mais peut également empêcher les fractionnements de page.

  • DATABASE_D - La base de données [DATABASE_D] contient 663 objets avec un facteur de remplissage = 70%. Cela peut entraîner des problèmes de performances de mémoire et de stockage, mais peut également empêcher les fractionnements de page.

  • DATABASE_E - La base de données [DATABASE_E] contient 335 objets avec un facteur de remplissage = 70%. Cela peut entraîner des problèmes de performances de mémoire et de stockage, mais peut également empêcher les fractionnements de page.

  • DATABASE_F - La base de données [DATABASE_F] contient 1705 objets avec un facteur de remplissage = 70%. Cela peut entraîner des problèmes de performances de mémoire et de stockage, mais peut également empêcher les fractionnements de page.

  • DATABASE_G - La base de données [DATABASE_G] contient 671 objets avec un facteur de remplissage = 70%. Cela peut entraîner des problèmes de performances de mémoire et de stockage, mais peut également empêcher les fractionnements de page.

  • DATABASE_H - La base de données [DATABASE_H] a 2364 objets avec un facteur de remplissage = 70%. Cela peut entraîner des problèmes de performances de mémoire et de stockage, mais peut également empêcher les fractionnements de page.

  • DATABASE_I - La base de données [DATABASE_I] contient 1658 objets avec un facteur de remplissage = 70%. Cela peut entraîner des problèmes de performances de mémoire et de stockage, mais peut également empêcher les fractionnements de page.

  • DATABASE_Z - La base de données [DATABASE_Z] contient 673 objets avec un facteur de remplissage = 70%. Cela peut entraîner des problèmes de performances de mémoire et de stockage, mais peut également empêcher les fractionnements de page.

  • DATABASE_K - La base de données [DATABASE_K] contient 312 objets avec un facteur de remplissage = 70%. Cela peut entraîner des problèmes de performances de mémoire et de stockage, mais peut également empêcher les fractionnements de page.

  • DATABASE_J - La base de données [DATABASE_J] a 864 objets avec un facteur de remplissage = 70%. Cela peut entraîner des problèmes de performances de mémoire et de stockage, mais peut également empêcher les fractionnements de page.

  • DATABASE_L - La base de données [DATABASE_L] contient 1170 objets avec un facteur de remplissage = 70%. Cela peut entraîner des problèmes de performances de mémoire et de stockage, mais peut également empêcher les fractionnements de page.

  • DATABASE_M - La base de données [DATABASE_M] contient 382 objets avec un facteur de remplissage = 70%. Cela peut entraîner des problèmes de performances de mémoire et de stockage, mais peut également empêcher les fractionnements de page.

  • DATABASE_O - La base de données [DATABASE_O] contient 356 objets avec un facteur de remplissage = 70%. Cela peut entraîner des problèmes de performances de mémoire et de stockage, mais peut également empêcher les fractionnements de page.

  • msdb - La base de données [msdb] contient 8 objets avec un facteur de remplissage = 70%. Cela peut entraîner des problèmes de performances de mémoire et de stockage, mais peut également empêcher les fractionnements de page.

  • DATABASE_P - La base de données [DATABASE_P] contient 291 objets avec un facteur de remplissage = 70%. Cela peut entraîner des problèmes de performances de mémoire et de stockage, mais peut également empêcher les fractionnements de page.

  • DATABASE_Q - La base de données [DATABASE_Q] contient 343 objets avec un facteur de remplissage = 70%. Cela peut entraîner des problèmes de performances de mémoire et de stockage, mais peut également empêcher les fractionnements de page.

  • DATABASE_R - La base de données [DATABASE_R] contient 2048 objets avec un facteur de remplissage = 70%. Cela peut entraîner des problèmes de performances de mémoire et de stockage, mais peut également empêcher les fractionnements de page.

  • DATABASE_S - La base de données [DATABASE_S] contient 325 objets avec un facteur de remplissage = 70%. Cela peut entraîner des problèmes de performances de mémoire et de stockage, mais peut également empêcher les fractionnements de page.

  • DATABASE_T - La base de données [DATABASE_T] contient 322 objets avec un facteur de remplissage = 70%. Cela peut entraîner des problèmes de performances de mémoire et de stockage, mais peut également empêcher les fractionnements de page.

  • DATABASE_U - La base de données [DATABASE_U] contient 351 objets avec un facteur de remplissage = 70%. Cela peut entraîner des problèmes de performances de mémoire et de stockage, mais peut également empêcher les fractionnements de page.

  • DATABASE_V - La base de données [DATABASE_V] contient 312 objets avec un facteur de remplissage = 70%. Cela peut entraîner des problèmes de performances de mémoire et de stockage, mais peut également empêcher les fractionnements de page.

  • DATABASE_X - La base de données [DATABASE_X] contient 352 objets avec un facteur de remplissage = 70%. Cela peut entraîner des problèmes de performances de mémoire et de stockage, mais peut également empêcher les fractionnements de page.

  • tempdb - La base de données [tempdb] contient 2 objets avec un facteur de remplissage = 70%. Cela peut entraîner des problèmes de performances de mémoire et de stockage, mais peut également empêcher les fractionnements de page.

• De nombreux plans pour une seule requête - 20763 plans sont présents pour une seule requête dans le cache de plan - ce qui signifie que nous avons probablement des problèmes de paramétrage.

• Déclencheurs de serveur activés - Le déclencheur de serveur [connection_limit_trigger] est activé. Assurez-vous de comprendre ce que fait ce déclencheur - moins il fait de travail, mieux c'est.

• Procédure stockée AVEC RECOMPILE

  • master - [master]. [dbo]. [sp_AllNightLog] contient WITH RECOMPILE dans le code de procédure stockée, ce qui peut entraîner une utilisation accrue du processeur en raison de recompilations constantes du code.

  • master - [master]. [dbo]. [sp_AllNightLog_Setup] contient WITH RECOMPILE dans le code de procédure stockée, ce qui peut entraîner une utilisation accrue du processeur en raison de recompilations constantes du code.

Priorité 110: performances :

• Tables actives sans index cluster

  • DATABASE_A - La base de données [DATABASE_A] contient des tas - tables sans index cluster - qui sont activement interrogés.

  • DATABASE_B - La base de données [DATABASE_B] contient des tas - des tables sans index cluster - qui sont activement interrogés.

  • DATABASE_C - La base de données [DATABASE_C] contient des tas - tables sans index cluster - qui sont activement interrogés.

  • DATABASE_E - La base de données [DATABASE_E] contient des tas - tables sans index cluster - qui sont activement interrogés.

  • DATABASE_F - La base de données [DATABASE_F] contient des tas - tables sans index cluster - qui sont activement interrogés.

  • DATABASE_H - La base de données [DATABASE_H] contient des tas - des tables sans index cluster - qui sont activement interrogés.

  • DATABASE_I - La base de données [DATABASE_I] contient des tas - tables sans index cluster - qui sont activement interrogés.

  • DATABASE_K - La base de données [DATABASE_K] contient des tas - tables sans index cluster - qui sont activement interrogés.

  • DATABASE_O - La base de données [DATABASE_O] a des tas - tables sans index cluster - qui sont activement interrogés.

  • DATABASE_Q - La base de données [DATABASE_Q] contient des tas - des tables sans index cluster - qui sont activement interrogés.

  • DATABASE_S - La base de données [DATABASE_S] contient des tas - tables sans index cluster - qui sont activement interrogés.

  • DATABASE_T - La base de données [DATABASE_T] contient des tas - tables sans index cluster - qui sont activement interrogés.

  • DATABASE_U - La base de données [DATABASE_U] contient des tas - tables sans index cluster - qui sont activement interrogés.

  • DATABASE_V - La base de données [DATABASE_V] contient des tas - tables sans index cluster - qui sont activement interrogés.

  • DATABASE_X - La base de données [DATABASE_X] contient des tas - tables sans index cluster - qui sont activement interrogés.

Priorité 150: Performance :

(Remarque: Nany conseille ici, mais je n'ai pas pu les inclure en raison de la limitation des caractères. S'il existe une autre façon de partager, veuillez l'indiquer.)

Vous nous avez posé une longue (et très détaillée) question. Vous devez maintenant faire face à une longue réponse. ;)

Il y a plusieurs choses que je suggérerais de changer sur votre serveur. Mais commençons par le problème le plus urgent.

Mesures d'urgence ponctuelles:

Le fait que les performances soient satisfaisantes après le déploiement des index sur votre système et les performances qui se dégradent lentement est un indice très fort dont vous avez besoin pour commencer à maintenir vos statistiques et (dans une moindre mesure) prendre en charge la framentation des index.

En tant que mesure d'urgence, je suggère une mise à jour manuelle unique des statistiques sur toutes vos bases de données. Vous pouvez obtenir le TSQL nécessaire en exécutant ce script:

DECLARE @SQL VARCHAR(1000)  
DECLARE @DB sysname  

DECLARE curDB CURSOR FORWARD_ONLY STATIC FOR  
   SELECT [name]  
   FROM master..sysdatabases 
   WHERE [name] NOT IN ('model', 'tempdb') 
   ORDER BY [name] 

OPEN curDB  
FETCH NEXT FROM curDB INTO @DB  
WHILE @@FETCH_STATUS = 0  
   BEGIN  
       SELECT @SQL = 'USE [' + @DB +']' + CHAR(13) + 'EXEC sp_updatestats' + CHAR(13)  
       PRINT @SQL  
       FETCH NEXT FROM curDB INTO @DB  
   END  

CLOSE curDB  
DEALLOCATE curDB

Il est fourni par Tim Ford dans son blogpost sur mssqltips.com et il explique aussi pourquoi la mise à jour des statistiques matière.

Veuillez noter qu'il s'agit d'une tâche intensive de CPU et d'E / S qui ne doit pas être effectuée pendant les heures de bureau.

Si cela résout votre problème, ne vous arrêtez pas là!

Maintenance régulière:

Jetez un œil à la solution de maintenance Ola Hallengren , puis configurez au moins ces deux tâches:

• Un travail de mise à jour des statistiques (si possible tous les soirs). Vous pouvez utiliser ce code CMD dans votre travail d'agent. Ce travail doit être créé à partir de zéro.

sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d MSSYS -Q "EXECUTE dbo.IndexOptimize @Databases = 'USER_DATABASES', @FragmentationLow = NULL, @FragmentationMedium = NULL, @FragmentationHigh = NULL, @UpdateStatistics = 'ALL', @OnlyModifiedStatistics = 'Y', @MaxDOP = 0, @LogToTable = 'Y'" -b

• Un travail de maintenance d'index. Je suggère de commencer par une exécution planifiée une fois par mois. Vous pouvez commencer avec les valeurs par défaut fournies par Ola pour le travail IndexOptimize.

Il y a plusieurs raisons pour lesquelles je suggère le premier travail pour mettre à jour les statistiques séparément:

• Une reconstruction d'index ne mettra à jour que les statistiques des colonnes couvertes par cet index tandis qu'une réorganisation d'index ne met pas du tout à jour les statistiques. Ola sépare la fragmentation en trois catégories. Par défaut, seuls les index élevés de catégorie seront reconstruits.
• Les statistiques des colonnes non couvertes par un index seront uniquement mises à jour par le travail IndexOptimize.
• Pour atténuer le problème de la clé ascendante .

SQL Server mettra automatiquement à jour les statistiques si la valeur par défaut est activée. Le problème avec ce sont les seuils (moins de problème avec votre SQL Server 2016). Les statistiques sont mises à jour lorsqu'une certaine quantité de lignes change (20% dans les anciennes versions de SQL Server). Si vous avez de grands tableaux, cela peut entraîner de nombreux changements avant la mise à jour des statistiques. Voir plus d'informations sur les seuils ici .

Puisque vous faites des CHECKDB pour autant que je sache, vous pouvez continuer à les faire comme avant ou vous utilisez également la solution de maintenance pour cela.

Pour plus d'informations sur la fragmentation et la maintenance des index, consultez:

Présentation de la fragmentation d'index SQL Server

Arrêtez de vous soucier de la fragmentation de SQL Server

Compte tenu de votre sous-système de stockage, je vous suggère de ne pas trop vous attarder sur la "fragmentation externe" car les données ne sont pas stockées dans l'ordre sur votre SAN de toute façon.

Optimisez vos paramètres

Le script sp_Blitz vous donne une excellente liste pour commencer.

Priorité 20: Configuration des fichiers - TempDB sur le lecteur C: parlez-en à votre administrateur de stockage. Demandez-leur si votre lecteur C est le disque le plus rapide disponible pour votre serveur SQL. Sinon, mettez votre tempdb là ... point. Vérifiez ensuite le nombre de fichiers temdb dont vous disposez. Si la réponse est une solution, cela . S'ils ne sont pas de la même taille, corrigez les deux.

Priorité 50: Informations sur le serveur - Initialisation instantanée des fichiers non activée: suivez le lien que le script sp_Blitz vous donne et activez IFI.

Priorité 50: Fiabilité - Vérification de la page non optimale: vous devez rétablir ce paramètre par défaut (CHECKSUM). Suivez le lien que le script sp_Blitz vous donne et suivez les instructions.

Priorité 100: Performances - Facteur de remplissage modifié: demandez-vous pourquoi il y a tant d'objets dont le facteur de remplissage est défini sur 70. Si vous n'avez pas de réponse et qu'aucun fournisseur d'application ne l'exige strictement. Réglez-le à 100%.

Cela signifie essentiellement que SQL Server laissera 30% d'espace vide sur ces pages. Donc, pour obtenir la même quantité de données (par rapport à 100% de pages pleines), votre serveur doit lire 30% de pages en plus et il faudra 30% d'espace en plus en mémoire. La raison pour laquelle cela est souvent fait est d'empêcher la fragmentation de l'index.

Mais encore une fois, votre stockage enregistre ces pages dans différents morceaux de toute façon. Je le ramènerais donc à 100% et le reprendrais à partir de là.

Que faire si tout le monde est content:

• Voir le reste de la sortie de sp_Blitz et décidez si vous les modifiez comme suggéré.
• Exécutez sp_BlitzIndex et examinez les index que vous avez créés, s'ils sont utilisés ou s'il peut y avoir une possibilité d'en ajouter / modifier un.
• Jetez un œil à vos données Query Store (comme suggéré par Peter). Vous pouvez trouver une introduction ici .
• Profitez de la rock-star en direct qu'un DBA mérite. ;)

En ne tenant pas compte de toutes vos réponses qui ont été très utiles et que j'ai appliquées ou appliquerai, le plus gros problème n'a pas été facile à trouver.

Le problème s'est aggravé dans les jours qui ont suivi nos derniers messages.

Étant donné que nous sommes basés sur le cloud, ni moi ni la société qui gère l'infrastructure et nous fournit le support n'a accès aux hôtes physiques.

Quelque chose m'a fait me demander quand j'ai remarqué que certains jours, le processeur était en moyenne à 20% et d'autres jours, il était beaucoup plus élevé, plus de 60%, lorsque la charge de travail, bien que jamais exactement la même, est similaire. Il y a le même nombre de personnes effectuant plus ou moins le même type d'opérations.

Plus tôt cette semaine, les utilisateurs ont commencé à rester bloqués pendant plusieurs minutes et seul le processeur a été étranglé. J'ai demandé à plusieurs utilisateurs de se déconnecter (ceux qui dépensaient plus de ressources mais toujours rien d'extraordinaire), j'ai désactivé divers services liés à la base de données, et au final rien n'a changé. J'ai demandé à l'administrateur système qui nous prend en charge et qui peut communiquer avec les gars de notre cloud à distance de ma machine de voir ce que je voyais et de m'aider à trouver quelque chose, car je ne pouvais pas faire mieux pour trouver le problème.

Le technicien n'a également rien trouvé. Il a finalement commencé à me donner une raison pour laquelle quelque chose d'autre devait être à l'origine de ce problème et c'est quand il a contacté le cloud. Dans le cloud, ils n'ont rien réalisé, juste que parce qu'il y a un équilibrage de charge configuré entre les hôtes physiques, la machine virtuelle qui prend en charge notre SQL Server a été déplacée plusieurs fois ce jour-là entre les hôtes physiques. Heureusement, j'ai dit à notre technicien exactement à quelle heure les problèmes ont commencé à se produire ce jour-là, ce qui coïncidait avec le moment où la machine virtuelle avait été déplacée la dernière fois vers l'un des hôtes physiques dont elle n'avait pas quitté le reste de la journée.

Si le technicien n'avait pas suivi de près ce problème, ce serait plus un de ces moments où il pourrait même parler aux gars du cloud, mais quand ils voyaient des échantillons de performances, ils n'obtiendraient rien, car encore une fois le cloud ne voyait que des échantillons avec CPU de l'ordre de 40/50%, alors qu'en fait il était en moyenne supérieur à 80% et souvent bloqué à 100%.

Maintenant, la machine se tient sur un hôte physique (ne se déplace pas entre les hôtes) et bien que nous n'ayons pas encore atteint les performances parfaites, tout le monde travaille et donne des retours beaucoup plus positifs, car le CPU moyen est d'environ 20% avec tous nos utilisateurs et prestations de service.

En attendant, nous avons également mis tempdb sur un autre disque (c'était sur le disque du système d'exploitation) et nous avons augmenté les fichiers, pour être plus en accord avec le nombre de cœurs des CPU.

Le nombre de cœurs a également été ajusté en fonction des recommandations de sp_Blitz.

Il y avait aussi une routine automatique qui fonctionnait toute la journée sur la base d'une ancienne date ... et comme elle ne s'est pas terminée le matin à notre arrivée, et nous n'avons aucun moyen de vérifier si elle fonctionne ou non, j'ai quand même commencé à exécuter manuellement. Mais l'autre courait probablement encore et courait deux fois pendant cette période. Nous avons changé la date pour réduire le temps que cela prend, et maintenant il est tard dans la nuit. Mais ce n'était pas la solution, car elle a été résolue avant de nombreux problèmes que nous avions comme celui décrit ici.

Nous avons également réussi à demander à l'assistant ERP de planifier une réunion avec le fabricant.Nous allons donc montrer notre système et rechercher des suggestions, ainsi que clarifier certains doutes, car il y a des recommandations dans les vidéos de formation qui sont contraires à la plupart des recommandations, y compris Microsoft lui-même, comme Priority Boost on et Fill Factor 70%.

Étant donné que l'application dispose également d'un écran de maintenance, je vais rechercher la périodicité requise de cette maintenance et ce qui reste à faire en dehors de l'application. Mon idée est d'utiliser les plans d'Ola Hallengren.

Je crois que la réponse de Thomas Kronawitter est absolument correcte et je l'applique, cependant, je pense que cette description peut être importante pour d'autres personnes qu'après avoir suivi toutes les bonnes pratiques ne peut toujours pas résoudre le problème car elle peut être dans les hôtes physiques . Merci Thomas.