DBCC CHECKDB 不仅仅会修复索引，检查指定数据库中的所有对象的分配和结构完整性。 

对于数据库中每个表，DBCC CHECKDB 检查其： 
索引和数据页是否已正确链接。 
索引是否按照正确的顺序排列。 
各指针是否一致。 
每页上的数据是否均合理。 
页面偏移量是否合理。 


所以关键在于你是否只是希望重建索引，如果这样的话，可能使用下面的更好点： 
DBCC DBREINDEX('database_name.owner.table_name',index_name,fillfactor)

------解决方案--------------------
一般在比较空闲时间操作吧,像论坛升级,数据升级等都是等到空闲时间的,不过楼主的研究精神是要学习的.

------解决方案--------------------
sql2k下，楼主的这个要求应该是不能完成的。

------解决方案--------------------
探讨

sql2k下，楼主的这个要求应该是不能完成的。


------解决方案--------------------
银行系统都有停的时候.总有个时间可以停吧.

------解决方案--------------------
探讨

DBCC不行吗? 

SQL code
DBCC CHECKDB 不仅仅会修复索引，检查指定数据库中的所有对象的分配和结构完整性。 

对于数据库中每个表，DBCC CHECKDB 检查其： 
索引和数据页是否已正确链接。 
索引是否按照正确的顺序排列。 
各指针是否一致。 
每页上的数据是否均合理。 
页面偏移量是否合理。 


所以关键在于你是否只是希望重建索引，如果这样的话，可能使用下面的更好点： 
DBCC DBREINDEX('database_name.owner.…


------解决方案--------------------
一般情况下，oracle可以用rebuild方式重建索引， 而不要先drop再create.
因为rebuild下，旧索引会保留到重建工作完成后才删除的。

------解决方案--------------------
sql 2000 无法实现.
sql 2005/2008 可以用REBUILD WITH ONLINE = ON 在索引操作期间不持有长期表锁.

------解决方案--------------------
探讨

一般情况下，oracle可以用rebuild方式重建索引， 而不要先drop再create. 
因为rebuild下，旧索引会保留到重建工作完成后才删除的。 
---------------- 
恩。我也一直在想。Rebuild的时候如果同一个索引做两个，等新索引建好的时候将旧的删除，然后新索引改名就好了。 
我试过在一张表的某个字段A上建两个索引，然后删除旧的。好像是可以的。但是主键怎么办？一张表只允许一个主键。麻烦了。呵呵。


------解决方案--------------------
引用

DBCC INDEXDEFRAG is an online operation. While this operation is running, the underlying table is available to users of the database. A relatively unfragmented index can be defragmented faster than a new index can be built because the time to defragment is related to the amount of fragmentation. A very fragmented index might take considerably longer to defragment than to rebuild.  In addition, the defragmentation is always fully logged, regardless of the database recovery model setting (see ALTER DATABASE). The defragmentation of a very fragmented index can generate more log than even a fully logged index creation. The defragmentation, however, is performed as a series of short transactions and thus does not require a large log if log backups are taken frequently or if the recovery model setting is SIMPLE.


------解决方案--------------------
不是不锁，是不长期占用锁，理论上是每隔 5 分钟向有一次向用户报告进展，可以任意中断执行，并且已经执行的都将保存。
如果数据量不大那是华得来的，比重建快得多，如果量大可以尽量空闲时分多次执行

------解决方案--------------------
我就是说嘛

------解决方案--------------------