web-dev-qa-db-fra.com

DUTENSIONS TEMPDB

Nous avons une base de données Active OLTP 40 Go sur SQL Server 2014 SP1. Les requêtes se trouvent lentement avec les attentes IO_Complettion, la longueur de la file d'attente de disque hausse à 900 et SQL Server cesse de répondre. Ce que nous avons essayé:

  1. Redémarrez l'instance et avec une minute, cela commence à se comporter de la même manière.

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

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

Cela s'est passé deux fois par mois. Chaque fois que j'ajoute un peu d'espace manuellement aux fichiers de données, alors il commence à fonctionner normalement. La chose la plus intéressante est que la même configuration (même matériel, le même dossier et la même configuration des fichiers, la même charge de travail) que nous avons sur SQL Server 2008 R2 et et SQL Server 2012 fonctionne bien.

Veuillez nous aider à trouver une solution permanente.

La taille initiale de tous les fichiers de données est la même de 1000 Mo, le courant est de 1500 Mo chacun. Tous sont identiques. Autogrowth est de 100 Mo pour chacun. Avant cela, nous étions confrontés à la discorde des pages de PFS et de GAM et nous avons augmenté à 16 et résolus. Les deux drapeaux de trace 1117 et 1118 sont activés. 24 noyaux sur 2 nœuds numa. Tous les datafiles sont sur le même volume. Disque simple, pas de san.

L'instance est sur une machine physique. Les requêtes avec des variables de table et des requêtes avec des jointures de hachage sont la plus génératrice des attentes IO_Completion.

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

Autogrow of Fichier 'Templog' dans la base de données 'TEMPDB' a été annulé par l'utilisateur ou expiré après 7704 millisecondes. Utilisez la base de données Alter pour définir une valeur de fileGrowth plus petite pour ce fichier ou définir explicitement une nouvelle taille de fichier.

Nous avons trouvé dans le journal quand ce type de problème se produit. Nous ouvrons TEMPDB pour séparer le lecteur rapide.

sql-serversql-server-2014tempdb
14
aasim.abdullah

Je pense que vous avez surprené votre TEMPDB et vous trouverez une inadéquation entre la CPU du serveur et la configuration du disque, mais collectons quelques informations supplémentaires:

Questions/Informations complémentaires requises

  • Veuillez confirmer le nom et le type de processeur (j'essaie essentiellement d'établir s'il s'agit de 2 x hex-noyau avec HT). Utilisez des informations système (p. Ex. Panneau de configuration> Système et Sécurité> Système sur Windows Server 2012 R2) et/ou Sysinternals Tool coreinfo pour confirmer.
  • Veuillez confirmer le serveur MaxDop (par exemple, EXEC sp_configure 'max degree of parallelism'). Si les processeurs sont hex-noyau, le serveur MaxDop doit être au plus 6 (selon tel ), ou sans subissablement plus bas sur un OLTP Système. Je garde normalement mon TEMPDB Fichiers en ligne avec mon serveur DOP à un maximum de 8 mais nous allons venir sur cela.
  • Veuillez confirmer la mémoire totale du serveur sur la case et le capuchon de 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 case (par exemple, SSIS, SSAS, SSRS, l'application, iTunes, etc.)
  • Veuillez confirmer que l'initialisation du fichier instantané est activée pour le compte de service SQL Server. (Façons de le tester ici ).
  • Pourquoi existe-t-il une telle différence entre la CPU (Configuration Numa Numa Beefy 2 Numa) Verus (Home PC)? Envisagez d'ajouter des disques, une bande de bande, SSD pour tempdb (bien qu'évité sur-réagissage :).
  • Veuillez ajouter un plan d'exécution réel pour l'une des questions de problème. Anonymise avec SQL Sentry plan explorateur Si vous le souhaitez.

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

    DECLARE @t TABLE ( x INT )

  • Ne lésinez pas sur la définition de la variable de table, même s'il contient de petits résultats. Il est toujours préférable de donner à l'optimiseur autant d'informations que possible, il est donc explicite avec la nullabilité, l'unicité, que l'indice soit ou non groupé/non 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

  • L'affichage du plan d'exécution aidera à diagnostiquer ceci.

  • Vérifiez le code prévention de la mise en cache variable de table selon ici , ICI . Je pense que Dynamic SQL et Proc exécuté avec recompilation sont les seuls à affecter les variables de la 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> SQL Server Logs) pour les messages, par exemple IO AVERTISSEMENTS.

  • Vérifiez Windows Event Viewer
  • Il y a eu un certain nombre de constructions libérées depuis SP1. Passez en revue les Cu des correctifs placés depuis SP1 . Il est possible qu'il existe des bugs dans SP1 fixé dans des CU ultérieures, par exemple la solution: trier des opérateurs se répand sur Tempdb dans SQL Server 2012 ou SQL Server 2014 Lorsque le nombre estimé de lignes et de taille de ligne est correct https://support.microsoft. com/fr-nous/kb/308848
  • Établissez ceci est votre cause avant d'appliquer des correctifs, bien qu'il soit plus important de rester à jour avec les CUS avec SQL Server 2014, en raison du nombre de nouvelles fonctionnalités (OLTP en mémoire OLTP, Colonne en cluster).
  • Enfin, la nécessité d'un fichier tempdb par noyau est un mythe et en regardant votre configuration de disque, ma supposion est TEMPDB est trop fragmentée. J'ai une sensation de naging que vous avez une tête de disque, TEMPDB a un groupe de fichiers, de nombreux fichiers.

Cependant, oubliez ce que nous pensons que nous savons; Créez une plate-forme de test qui reproduit votre problème et expérimentez la réduction du nombre de fichiers temporaires ... Commencez à 1, 2, 4, 6, etc. Recueillir les informations, pour prendre une décision fondée sur des preuves. Maintenant, c'est plus difficile que votre problème semble intermittent et que vous ne pourrez peut-être pas gâcher avec votre configuration tempdb, mais c'est comme ça que je voudrais aborder cela.

Bonne chance. Fais nous savoir comment tu reussis.

6
wBob