<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Tempdb on Rudi Bruchez</title><link>https://www.pachadata.com/tags/tempdb/</link><description>Recent content in Tempdb on Rudi Bruchez</description><generator>Hugo</generator><language>fr</language><lastBuildDate>Mon, 02 Nov 2026 07:17:53 +0100</lastBuildDate><atom:link href="https://www.pachadata.com/tags/tempdb/index.xml" rel="self" type="application/rss+xml"/><item><title>Réduire la taille de tempdb</title><link>https://www.pachadata.com/docs/howtos/maintenance-des-bases/shrink-tempdb/</link><pubDate>Sun, 01 Nov 2026 00:00:00 +0000</pubDate><guid>https://www.pachadata.com/docs/howtos/maintenance-des-bases/shrink-tempdb/</guid><description>&lt;p&gt;&lt;em&gt;Article coécrit avec Claude, qui a mené les tests en labo et la lecture de la documentation.&lt;/em&gt;&lt;/p&gt;&#10;&lt;div class="alert alert-success" role="alert"&gt;&lt;div class="h4 alert-heading" role="heading"&gt;TL;DR&lt;/div&gt;&#10;&lt;p&gt;Un redémarrage de SQL Server recrée &lt;code&gt;tempdb&lt;/code&gt; à sa taille configurée : c&amp;rsquo;est la seule réduction garantie. À chaud, &lt;code&gt;DBCC SHRINKFILE&lt;/code&gt; fonctionne, mais il peut attendre les requêtes qui débordent dans &lt;code&gt;tempdb&lt;/code&gt;, et il s&amp;rsquo;arrête sur les &lt;em&gt;work tables&lt;/em&gt;, y compris celles qu&amp;rsquo;un plan en cache garde après la fin de la requête.&#10;Un shrink qui s&amp;rsquo;arrête avant sa cible, &lt;code&gt;TRUNCATEONLY&lt;/code&gt; compris, fixe la taille de démarrage là où il s&amp;rsquo;est arrêté : contrôlez &lt;code&gt;sys.master_files&lt;/code&gt; après coup, et corrigez par &lt;code&gt;ALTER DATABASE tempdb MODIFY FILE&lt;/code&gt;.&lt;/p&gt;&#10;&lt;/div&gt;</description></item></channel></rss>