<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Sys.dm_exec_cached_plans on SQL Server Scripts</title><link>https://www.sqlserver70.com/tags/sys.dm_exec_cached_plans/</link><description>Recent content in Sys.dm_exec_cached_plans on SQL Server Scripts</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>SQLServer70.com</copyright><lastBuildDate>Sat, 06 Jun 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://www.sqlserver70.com/tags/sys.dm_exec_cached_plans/index.xml" rel="self" type="application/rss+xml"/><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>