<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Index Fragmentation on SQL Server Scripts</title><link>https://www.sqlserver70.com/tags/index-fragmentation/</link><description>Recent content in Index Fragmentation on SQL Server Scripts</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>SQLServer70.com</copyright><lastBuildDate>Fri, 05 Jun 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://www.sqlserver70.com/tags/index-fragmentation/index.xml" rel="self" type="application/rss+xml"/><item><title>SQL Server DBCC SHRINKDATABASE: When and When Not to Shrink</title><link>https://www.sqlserver70.com/post/sql-server-dbcc-shrinkdatabase-when-to-shrink/</link><pubDate>Fri, 05 Jun 2026 00:00:00 +0000</pubDate><guid>https://www.sqlserver70.com/post/sql-server-dbcc-shrinkdatabase-when-to-shrink/</guid><description>
&lt;p&gt;A one-time data load doubled a data file overnight, the load is done, the rows are deleted, and the file is now mostly empty space. The reflex — reach for &lt;code&gt;DBCC SHRINKDATABASE&lt;/code&gt; and give the disk back — is one of the most common self-inflicted performance wounds in SQL Server administration. This post explains exactly what shrinking does to your indexes, when it is genuinely the right call, and how to reclaim space the few times you must without wrecking performance.&lt;/p&gt;</description></item><item><title>DBCC DBREINDEX vs ALTER INDEX REBUILD in SQL Server</title><link>https://www.sqlserver70.com/post/sql-server-dbcc-dbreindex-vs-alter-index-rebuild/</link><pubDate>Wed, 03 Jun 2026 00:00:00 +0000</pubDate><guid>https://www.sqlserver70.com/post/sql-server-dbcc-dbreindex-vs-alter-index-rebuild/</guid><description>
&lt;p&gt;Open the SQL Agent job history on an instance that has been running for a decade and you will still find &lt;code&gt;DBCC DBREINDEX&lt;/code&gt; in a nightly maintenance step, quietly doing its job. It works — which is exactly why nobody has touched it. But it has been deprecated for the better part of twenty years, it locks tables it does not need to lock, and it cannot do the things modern index maintenance takes for granted. This post compares it to its replacement and shows the one-afternoon migration to &lt;code&gt;ALTER INDEX&lt;/code&gt;.&lt;/p&gt;</description></item></channel></rss>