web-dev-qa-db-fra.com

Pourquoi la réduction du journal TEMPDB entraînerait-elle une lenteur?

J'ai récemment réduit accidentellement le journal tempdb à presque 0 après avoir été averti que le lecteur de journal se remplissait. On me dit que cela entraînera une lenteur. Quelqu'un peut-il expliquer pourquoi cela entraînera une lenteur?

sql-servertransaction-logtempdb
11
user193020

Je demanderais à la personne qui vous a dit cela, au moins d'entendre pourquoi elle pense que cela réduira les performances.

L'une des raisons est que votre TLOG ne restera pas à 0. Puisque vous l'avez réduit si petit, je suppose que vous avez réglé la croissance automatique. Selon la façon dont vous l'avez configuré, il augmentera à chaque fois un montant défini ou un pourcentage de sa taille à chaque fois. Ainsi, chaque fois que votre journal des transactions doit augmenter, SQL Server doit faire un travail, que vous pourriez remarquer en termes de performances.

Une raison principale est détaillée dans le premier lien ci-dessous:

Lorsque le mécanisme de croissance automatique du journal des transactions entre en action, SQL Server doit toujours initialiser à zéro le nouveau segment ajouté à la fin du fichier . Peu importe que votre instance SQL Server s'exécute avec le privilège Instant File Initialization, ou non - le journal des transactions est toujours initialisé à zéro.

Ce qui est plus logique consiste à définir un lecteur dédié pour ce fichier et à définir le fichier journal à la taille du lecteur. Pourquoi rétrécir à 0 alors que vous savez que cela ne fera que croître à nouveau, vous laissant au même endroit avec sa taille, provoquer une fragmentation, etc.?

tempdb utilise le modèle de récupération simple et efface le journal chaque fois qu'un point de contrôle est émis. Cela se produit automatiquement lorsque les utilisations du journal atteignent 70% et dans le cas de tempdb, il ne force pas les pages tempdb sales sur le disque. Voir le post de Paul Randall à ce sujet. Les VLF sont rendus inactifs si possible pendant le checkpoint également. Lorsque vous réduisez le journal, les VLF sont supprimés.

13
scsimon

Un point de plus à ajouter aux deux bonnes réponses existantes.

Une fois que vous avez décidé de la meilleure taille pour tempdb, vous devez la définir manuellement à cette taille. Si cela n'est pas fait lorsque SQL redémarre chaque mois alors que le système est corrigé (en supposant que vous effectuez des correctifs mensuels), il sera réinitialisé à la plus petite taille et devra augmenter, ce qui donnera les problèmes de performances mentionnés dans les autres réponses.

USE [master]
GO
ALTER DATABASE [tempdb] MODIFY FILE ( NAME = N'temp2', SIZE = 2560000KB )
GO
ALTER DATABASE [tempdb] MODIFY FILE ( NAME = N'tempdev', SIZE = 2560000KB )
GO

De plus, un paramètre de croissance automatique raisonnable est également fourni. Il doit s'agir d'une valeur en Mo, ne jamais utiliser de pourcentage.

6
James Jenkins

Lorsqu'un fichier se développe suite à une transaction, cette transaction est suspendue pendant la croissance du fichier. Toute autre transaction utilisant le fichier peut également être affectée. Cela s'ajoute à la pression que la croissance du fichier place sur les systèmes de fichiers, bien que la séparation de vos fichiers puisse y contribuer.

Les fichiers journaux, en particulier, doivent être développés et mis à zéro avant de pouvoir être utilisés. Vous pouvez toutefois activer l'initialisation instantanée des fichiers pour les fichiers de données.

Idéalement, vous devez laisser tempdb atteindre la taille dont il a besoin et le laisser là, bien que si une transaction erronée est à l'origine de la croissance, il est acceptable de la ramener à une taille normale. Mais le ramener à 0 n'était pas la meilleure mesure à prendre.

5
Jonathan Fite