Contentions TempDB

Nous avons une base de données OLTP active de 40 Go sur SQL Server 2014 SP1. Les requêtes s'avèrent lentes avec des attentes IO_Completion, la longueur de la file d'attente de disque passant à 900 et SQL Server cesse de répondre. Ce que nous avons essayé:

1. Redémarrez l'instance et, en une minute, elle commencera à se comporter de la même manière.

2. Après le deuxième redémarrage, nous avons changé la taille initiale de chaque fichier de données tempdb (il y a 16 fichiers de données créés) et il commence à fonctionner correctement.

Remarque: Nous utilisons des variables de table pour les jeux de résultats intermédiaires. Ces ensembles de résultats sont très petits.

C'est arrivé deux fois en un mois. Chaque fois que j'ajoute un peu d'espace manuellement aux fichiers de données, cela commence à fonctionner normalement. La chose la plus intéressante est que la même configuration (même matériel, même configuration de dossier et de fichiers, même charge de travail) que nous avons sur SQL Server 2008 R2 et SQL Server 2012 fonctionne correctement.

Veuillez nous aider à trouver une solution permanente.

La taille initiale de tous les fichiers de données est la même de 1 000 Mo, le courant est de 1 500 Mo chacun. Tous sont identiques. La croissance automatique est de 100 Mo pour chacun. Avant cela, nous étions confrontés à des conflits de pages PFS et GAM et nous sommes passés à 16 et le problème a été résolu. Les deux indicateurs de trace 1117 et 1118 sont activés. 24 cœurs sur 2 nœuds NUMA. Tous les fichiers de données sont sur le même volume. Disque simple, pas de SAN.

L'instance se trouve sur une machine physique. Les requêtes avec des variables de table et les requêtes avec des jointures de hachage génèrent le plus souvent des attentes IO_Completion.

La réponse détaillée de wBob nous a poussés à chercher plus en détail. Comment l'avons-nous manqué avant:

La croissance automatique du fichier 'templog' dans la base de données 'tempdb' a été annulée par l'utilisateur ou expirée après 7704 millisecondes. Utilisez ALTER DATABASE pour définir une valeur FILEGROWTH plus petite pour ce fichier ou pour définir explicitement une nouvelle taille de fichier.

Nous l'avons trouvé dans le journal chaque fois que ce type de problème se produit. Nous déplaçons TempDB pour séparer le lecteur rapide.

Je pense que vous avez surfragmenté votre tempdb et qu'il y a un décalage entre le processeur du serveur et la configuration du disque, mais collectons plus d'informations:

Questions / Informations supplémentaires requises

• Veuillez confirmer le nom et le type du processeur (j'essaie essentiellement de déterminer s'il s'agit de 2 x hex-core avec HT). Utilisez les informations système (par exemple, Panneau de configuration> Système et sécurité> Système sur Windows Server 2012 R2) et / ou l'outil sysinternals CoreInfo pour confirmer.
• Veuillez confirmer le serveur maxdop (par exemple EXEC sp_configure 'max degree of parallelism'). Si les CPU sont hex-core, le serveur maxdop devrait être au plus 6 (comme ici ), ou sans doute inférieur sur un système OLTP. Je garde normalement mes fichiers tempdb en ligne avec mon serveur DOP à un maximum de 8 mais nous y reviendrons.
• Veuillez confirmer la mémoire totale du serveur sur la boîte et le cap de la mémoire SQL Server (par exemple EXEC sp_configure 'max server memory (MB)').
• Veuillez confirmer si d'autres services sont en cours d'exécution sur la boîte (par exemple SSIS, SSAS, SSRS, l'application, iTunes, etc.)
• Veuillez confirmer que l'initialisation instantanée des fichiers est activée pour le compte de service SQL Server. (Façons de le tester ici ).
• Pourquoi y a-t-il une telle différence entre le CPU (configuration NUMA à 2 nœuds) et le disque (PC domestique)? Pensez à ajouter des disques, une répartition, un SSD pour tempdb (mais évitez de réagir de manière excessive:) .
• Veuillez ajouter un plan d'exécution réel pour l'une des requêtes problématiques. Anonymisez avec SQL Sentry Plan Explorer si vous le souhaitez.

• Hash se joint à des variables de table dans un système OLTP? Cela suggère un manque d'indexation sur la variable de table, la table principale ou les deux. Déclarez-vous vos variables de table comme ceci (sans index)?

  DECLARE @t TABLE ( x INT )

• Ne lésinez pas sur la définition de variable de table même si elle contient de petits ensembles de résultats. Il est toujours préférable de donner à l'optimiseur autant d'informations que possible, donc soyez explicite avec la nullité, l'unicité, que l'index soit ou non en cluster, par exemple

  DECLARE @t TABLE ( x INT PRIMARY KEY )
  DECLARE @u TABLE ( x INT PRIMARY KEY NONCLUSTERED, u INT NOT NULL UNIQUE CLUSTERED, z INT NOT NULL UNIQUE, a CHAR(1) NULL ) -- not sure why you would do this but you can
  DECLARE @v TABLE ( x INT NOT NULL, y INT NOT NULL, PRIMARY KEY ( x, y ) )   -- multi-column primary key

• La publication du plan d'exécution aidera à diagnostiquer cela.

• Vérifiez le code empêchant la mise en cache des variables de table comme ici , ici . Je pense que SQL dynamique et proc exécutés AVEC RECOMPILE sont les seuls qui affectent les variables de table.

  DECLARE @u TABLE ( x INT )
  
  INSERT @u
  EXEC('DECLARE @t TABLE ( x INT ); INSERT INTO @t VALUES ( 1 ); SELECT x FROM @t;' )
  
  SELECT *
  FROM @u

• Vérifiez le journal SQL Server (Explorateur d'objets> Gestion> Journaux SQL Server) pour les messages, par exemple les avertissements d'E / S.

• Vérifiez l'Observateur d'événements Windows
• Plusieurs versions ont été publiées depuis le SP1. Passez en revue les correctifs CU mis en place depuis SP1 . Il est possible que des bogues dans SP1 soient corrigés dans les CU suivantes, par exemple FIX: Triez les déversements d'opérateurs sur tempdb dans SQL Server 2012 ou SQL Server 2014 lorsque le nombre estimé de lignes et la taille des lignes sont corrects https://support.microsoft.com/en- nous / kb / 3088480
• Établir cela est votre cause avant d'appliquer des correctifs, bien qu'il soit plus important de se tenir à jour avec les CU avec SQL Server 2014, en raison du nombre de nouvelles fonctionnalités (OLTP en mémoire, columnstore en cluster).
• Enfin, le besoin d'un fichier tempdb par cœur est un mythe et en regardant la configuration de votre disque, je suppose que tempdb est trop fragmenté. J'ai l'impression que vous avez une tête de disque, tempdb a un groupe de fichiers, beaucoup de fichiers.

Mais oubliez ce que nous pensons savoir; créez une plate-forme de test qui reproduit votre problème, et expérimentez avec la réduction du nombre de fichiers temporaires ... commencez à 1, 2, 4, 6 etc. collectez les informations, pour prendre une décision fondée sur des preuves. Maintenant, c'est le plus difficile car votre problème semble intermittent et vous ne pourrez peut-être pas jouer avec votre configuration tempdb, mais c'est ainsi que j'aborderais cela.

Bonne chance. Fais nous savoir comment tu reussis.