<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Plan Cache on SQL Server Scripts</title><link>https://www.sqlserver70.com/tags/plan-cache/</link><description>Recent content in Plan Cache on SQL Server Scripts</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>SQLServer70.com</copyright><lastBuildDate>Mon, 08 Jun 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://www.sqlserver70.com/tags/plan-cache/index.xml" rel="self" type="application/rss+xml"/><item><title>SQL Server DBCC Commands: The Complete DBA Reference Guide</title><link>https://www.sqlserver70.com/post/sql-server-dbcc-commands-reference/</link><pubDate>Mon, 08 Jun 2026 00:00:00 +0000</pubDate><guid>https://www.sqlserver70.com/post/sql-server-dbcc-commands-reference/</guid><description>
&lt;p&gt;Every SQL Server instance ships with a parallel command vocabulary that never appears in an ORM, a stored procedure, or an application query: the DBCC statements. They validate physical page structure, reclaim file space, evict cached plans, reseed identity columns, and report internal counters that no &lt;code&gt;SELECT&lt;/code&gt; exposes — and a DBA who does not know which one to reach for in an incident reaches for the wrong one. This guide maps the DBCC surface area by family, shows a representative statement for each, and links to deep dives on the commands you run most.&lt;/p&gt;</description></item><item><title>SQL Server DBCC FREEPROCCACHE: Clear the Plan Cache Safely</title><link>https://www.sqlserver70.com/post/sql-server-dbcc-freeproccache-clear-plan-cache/</link><pubDate>Sat, 06 Jun 2026 00:00:00 +0000</pubDate><guid>https://www.sqlserver70.com/post/sql-server-dbcc-freeproccache-clear-plan-cache/</guid><description>
&lt;p&gt;A stored procedure that returned in 20 milliseconds yesterday is timing out today, and nothing in the code changed. The data did not grow meaningfully, the indexes are intact, and statistics look current — yet the query is suddenly scanning a million rows it used to seek. The usual culprit is a cached execution plan compiled for the wrong parameter value, and &lt;code&gt;DBCC FREEPROCCACHE&lt;/code&gt; is the scalpel that removes it. The danger is using it as a sledgehammer.&lt;/p&gt;</description></item></channel></rss>