|
|
Posted by Erland Sommarskog on 07/16/07 22:27
(alexander.arvidsson@gmail.com) writes:
> The creators of the software that my customer uses (two different
> systems) BOTH claim that using clustered indexes hampers performance,
> each and every time. I can't find ANY resource on the internet that
> validates this, quite the opposite. I am told that the best practices
> is to always us a clustered index on a table.
> Following their own guidelines, there is no clustered index in sight,
> and hence some tables have a whopping 30GB(!) of unused space.
SQL Server MVP Greg Linwood has argued fiercely for heaps, but it is
obvious that heaps require much more manual management. Else, you end
up with badly fragmented tables, as in your customer's case.
But if the developers think that clustered index is worse than sin, then
just set up a job that adds a clustered index to the table and then
drops it. It will run for a longer time than a regular reindexing,
as all non-clustered indexes will have to be rebuilt. Twice. Or drop
the non-clustered indexes first, and then add them back at the end.
Hopefully, someone will object to this and ask "isn't there a
simpler way?", whereupon you answer "sure, we could use a clustered
index instead, but it takes price to be on top".
If you can find the resources to set up a parallel environment as
DA suggested, then it should be an easy game.
--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
Navigation:
[Reply to this message]
|