home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.databases.ms-sqlserver      Notorious Rube Goldberg contraption      19,505 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 17,660 of 19,505   
   Erland Sommarskog to seanD   
   Re: defrag of 101G table, What is the be   
   03 Oct 09 10:07:47   
   
   7cdc20e3   
   From: esquel@sommarskog.se   
      
   seanD (sean.denney@gmail.com) writes:   
   > What is the best way to defragment a very large table if both minimal   
   > user impact and speed are concerns?   I have a small maintenance   
   > window And a 24X7 application on top of this database.  It seems that   
   > doing anything online would not make sense, but doing a rebuild   
   > offline will have large impact for the   
   > Application.  Is indexing a temptable and copying into it and renaming   
   > the best way to go?   
   >   
   > Any help you can give would really be appreciated.   
      
   What version and edition of SQL Server do you have?   
      
   If you have SQL 2005/2008 Enterprise, you can use the WITH ONLINE option   
   with ALTER INDEX REBUILD to make an online rebuild. The rebuild will still   
   not be 100% online, there will be small windows when the table is locked.   
   But most of the time table will be accessible.   
      
   The alternative is to use ALTER INDEX REORGANIZE which is always online.   
   Sometimes this is better, but it can also take a larger toll on the   
   application.   
      
   The alternative you suggest of copying data into a new table sounds like   
   the poor man's online defragmentation, which you would need to use if you   
   are on SQL 2000, or have Standard Edition. (But if you have a 24/7   
   requirement, I would suggest that this is a strong call to use Enterprise.)   
      
   > index 1 (Clustered) is on varchar(15)/varchar(36)  - 88% fragmentation   
   > index 2 nonunique on uniqueidentifier is 4%   
   > index 3 is primary key index on int col  is also 88% fragmented   
      
   It's a little intriguing that an index on a IDENTITY column would be   
   that badly fragmented. On the other hand, I would expect a guid index   
   to have realy poor numbers. From where did you get these numbers? You   
   did not by chance confuse then with scan density?   
      
      
      
   --   
   Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se   
      
   Links for SQL Server Books Online:   
   SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx   
   SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx   
   SQL 2000: http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca