Site sponsored by: Idera Try Idera’s new SQL admin toolset
SQL Server Performance

  • Home
  • Articles
  • Forums
  • Tips
  • Quiz
  • FAQ's
  • Blogs
  • Software
  • Books
  • About Us
RSS Feeds
Sign in | Join


FAQ Topics

All FAQ's
General DBA
General Developer
DBA Performance Tuning
Developer Performance Tuning
Clustering
Error Messages

Write for Us

Share you SQL Server knowledge with others and raise your profile in the community More...
Latest Articles

Capture DDL Changes using Change Data Capture with SQL Server 2008 ...
Business Intelligence in Collaborative Planning, Forecasting and Replenishment
Inside SQL Server Cluster Setup and Troubleshooting Techniques - Part I ...
Configure and Manage Policy Based Management in SQL Server 2008 ...

More     
 
Latest FAQ's

Cannot Start SQL Server Service
Users are able to connect to report manager but not able ...
Errors when SQL Server Snapshot Replication is Running
How to Display Server Name or IP Address in a Reporting ...

More     
   
Latest Software Reviews

Spotlight on ApexSQL Doc 2008
ApexSQL Enforce
Embarcadero Change Manager
SQL Server DBA Dashboard

More     

DBCC INDEXDEFRAG doesn't seem to work like it should.



Question

I have a very large table, over 30 million records, that has a logical fragmentation of about 60%, and this is even if I run DBCC INDEXDEFRAG on it. Is this normal, and if not, what can I do about reducing the fragmentation?

Answer

In SQL Server 2000, Microsoft introduced DBCC INDEXDEFRAG to help reduce logical disk fragmentation. When this command runs, it reduces fragmentation and does not lock the table, allowing other users to access the table when the defragmentation process is running. Unfortunately, this command doesn't do a great job of logical defragmentation, as you have noticed.

The only way to truly reduce logical fragmentation is to rebuild your table's indexes. While this will eliminate fragmentation, unfortunately it will lock each table at the indexes for the table are being reindexed, preventing users from accessing it during this process. This means that you will need to find a time when this will not present a problem to your users. And at 30 million rows, this could take a while, depending on the quantity and width of your indexes.

When you rebuild your indexes on this table, you will also want to select an appropriate fillfactor in order to prevent unnecessary page splits. The amount of the fillfactor will depend on how read or write intensive your table is. The more write intensive the table is, the greater the fill factor needs to be.

Also, for the long term, you will also want to consider scheduling an index rebuild periodically, such as once a week or once a month in order to prevent such sever logical fragmentation from happening again.








Home | Peformance Articles | Audit Articles | Business Intelligence Articles | Clustering Articles | Developer Articles | Reporting Services Articles | DBA Articles | ASP.NET / ADO.NET Articles | DBA FAQ's | Developer Peformance FAQ's | DBA Peformance FAQ's | Developer FAQ's | Clustering FAQ's | Error Messages | Audit Tool Reviews | Backup Tool Reviews | Coding Tool Reviews | Compare Tool Reviews | Documentation Tool Reviews | Design Tool Reviews | Monitoring Tool Reviews | Log Tool Reviews | Reporting Tool Reviews | Clustering Tool Reviews | Security Tool Reviews | Change Management Tool Reviews | Remote Access Tool Reviews | Book Reviews | Security Tool Reviews | QDPMA Performance Tuning | ADO.NET / ASP.NET | Administration | Analysis/OLAP Services | Application Development | Configuration | Components | ETL | Hardware | High Availability | Hints | Index | Misc | Operating Systems | Performance Tuning | Replication | T-SQL | Views


              © 1999-2008 by T10 Media. All rights reserved