典型问题2!索引的重建问题

Question

DBCC DBREINDEX
重建指定数据库中表的一个或多个索引。语法
DBCC DBREINDEX
    (    [ 'database.owner.table_name'    
            [ , index_name
                [ , fillfactor ]
            ] 
        ] 
    )    [ WITH NO_INFOMSGS ]参数
'database.owner.table_name'是要重建其指定的索引的表名。数据库、所有者和表名必须符合标识符的规则。有关更多信息，请参见使用标识符。如果提供 database 或 owner 部分，则必须使用单引号 (') 将整个 database.owner.table_name 括起来。如果只指定 table_name，则不需要单引号。index_name是要重建的索引名。索引名必须符合标识符的规则。如果未指定 index_name 或指定为 ' '，就要对表的所有索引进行重建。fillfactor是创建索引时每个索引页上要用于存储数据的空间百分比。fillfactor 替换起始填充因子以作为索引或任何其它重建的非聚集索引（因为已重建聚集索引）的新默认值。如果 fillfactor 为 0，DBCC DBREINDEX 在创建索引时将使用指定的起始 fillfactor。WITH NO_INFOMSGS禁止显示所有信息性消息（具有从 0 到 10 的严重级别）。注释
DBCC DBREINDEX 重建表的索引或为表定义的所有索引。通过允许动态重建索引，可以重建强制 PRIMARY KEY 或 UNIQUE 约束的索引，而不必除去并重新创建这些约束。这意味着不必知道表的结构或约束就可以重建索引，将数据大容量复制到表中后就会出现这种情况。 如果指定 index_name 或 fillfactor，还必须指定以前所有的参数。DBCC DBREINDEX 可以使用一条语句重建表的所有索引，这比对多个 DROP INDEX 和 CREATE INDEX 语句进行编码容易。由于该工作是通过一条语句完成的，所以 DBCC DBREINDEX 自动为原子性，而单个 DROP INDEX 和 CREATE INDEX 语句要成为原子性则必须放在事务中。另外，与使用单个 DROP INDEX 和 CREATE INDEX 语句相比，DBCC DBREINDEX 可从 DBCC DBREINDEX 的优化性能中更多地获益。不支持在系统表上使用 DBCC DBREINDEX。 结果集
不管是否指定任何选项（ NO_INFOMSGS 除外），DBCC DBREINDEX 返回以下结果集；下例使用 pubs 数据库的 authors 表（值可能会有变化）：Index (ID = 1) is being rebuilt.
Index (ID = 2) is being rebuilt.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.如果指定 NO_INFOMSGS 选项，DBCC DBREINDEX 将返回以下结果集（消息）：DBCC execution completed. If DBCC printed error messages, contact your system administrator.权限
DBCC DBREINDEX 权限默认授予表所有者、sysadmin 固定服务器角色或 db_owner 和 db_ddladmin 固定数据库角色的成员且不可转让。示例
A. 重建某个索引
下例使用填充因子 80 重建 pubs 数据库中 authors 表上的 au_nmind 聚集索引。DBCC DBREINDEX ('pubs.dbo.authors', UPKCL_auidind, 80)B. 重建所有索引
下例使用填充因子值 70 重建 authors 表上的所有索引。DBCC DBREINDEX (authors, '', 70)

Answer 1

--重建当前库中,所有表的索引exec sp_msforeachtable 'DBCC DBREINDEX(''?'')'

Answer 2

--重建当前库中,所有表的索引exec sp_msforeachtable 'DBCC DBREINDEX(''?'')'to 邹老大：
这条语句能不能在用户使用时执行呀。

Answer 3

问：这条语句能不能在用户使用时执行呀。
答：如果在用户使用时执行，用DBCC INDEXDEFRAG与 DBCC DBREINDEX（一般的索引生成操作）不同，DBCC INDEXDEFRAG 是联机操作。它不长期控制锁，因此不会防碍运行查询或更新。若索引的碎片相对较少，则整理该索引的速度比生成一个新索引要快，这是因为碎片整理所需的时间与碎片的数量有关。对碎片太多的索引进行整理可能要比重建花更多的时间。另外，始终对碎片整理进行完整的日志记录，与数据库恢复模型设置无关（请参见 ALTER DATABASE）。对碎片太多的索引进行整理所生成的日志记录可能比完全记录的索引创建还要多。然而，若需经常进行日志备份或如果恢复模型设置是 SIMPLE，碎片整理将作为一系列短事务执行，因此不需要大量的日志。 另外，如果两个索引在磁盘上交叉存取事务，DBCC INDEXDEFRAG 将没有作用，原因是 INDEXDEFRAG 打乱了已有的页。若要改善页的聚集，请重建索引。