关于Alter index的问题

[TLJewel]

sql2000里，为了整理碎片，有个DBCC 的方法，在sql2005里是不是被alter index取代了，我想了解下，谁能帮我找下相应的文章，或者帮忙做下简介。

注：让我自己找的就算了，我会自己找的，不过我想尝试新的学习方法，就是在最有效的时间里找到有用的资料，我想应该比我自己找更能发现一些自己没有注意到的事情。

[liangCK]

联机丛书->查DBCC 的命令..然后打开了..如果该命令是被新的语法所取代..微软就会说明..该命令不再推荐使用..

[liangCK]

[Quote=引用 1 楼 liangCK 的回复:]
联机丛书->查DBCC 的命令..然后打开了..如果该命令是被新的语法所取代..微软就会说明..该命令不再推荐使用..
[/Quote]

如果这样也不是最有效的方法..建议lz打电话给微软去问吧.

[rucypli]

[Quote=引用楼主 TLJewel 的帖子:]
sql2000里，为了整理碎片，有个DBCC 的方法，在sql2005里是不是被alter index取代了，我想了解下，谁能帮我找下相应的文章，或者帮忙做下简介。

注：让我自己找的就算了，我会自己找的，不过我想尝试新的学习方法，就是在最有效的时间里找到有用的资料，我想应该比我自己找更能发现一些自己没有注意到的事情。
[/Quote]

百度google

[dawugui]

2005仍然有DBCC CHECKDB 语句.在帮助中输入dbcc checkdb,里面有详细的介绍.

[dawugui]

示例

DBCC CHECKDB 
检查指定数据库中所有对象的分配、结构和逻辑完整性。

A. 检查当前数据库和 AdventureWorks 数据库
下面的示例将对当前数据库和 AdventureWorks 数据库执行 DBCC CHECKDB。
-- Check the current database.
DBCC CHECKDB;
GO
-- Check the AdventureWorks database without nonclustered indexes.
DBCC CHECKDB ('AdventureWorks', NOINDEX);
GO
 
B. 检查当前数据库，取消信息性消息
以下示例检查当前数据库，并取消所有信息性消息。

DBCC CHECKDB WITH NO_INFOMSGS;
GO
 

[dawugui]

备注
在 SQL Server 的早期版本中，用于每个表、每个索引行计数和页计数的值可能不正确。在特定情况下，其中的一个或多个值甚至会变为负值。DBCC CHECKDB 不检测这一问题。这不是由于数据库中存储的任何数据发生损坏而导致的，通常可通过运行 DBCC UPDATEUSAGE 命令来解决该问题。

在 SQL Server 2005 中，DBCC CHECKDB 得到增强，可以检测计数值之一变为负值这一情况。检测到上述问题后，DBCC CHECKDB 的输出会包含一个警告和一个建议，建议运行 DBCC UPDATEUSAGE 解决该问题。尽管看起来是由于将数据库升级到 SQL Server 2005 导致了该问题，但实际上升级之前便已存在这一情况。

注意：
使用 SQL Server 2005 创建的数据库中不会出现这一问题。



DBCC CHECKDB 不检查禁用的索引。有关禁用索引的详细信息，请参阅禁用索引。

关于其操作的有用总结是在内部运行 DBCC CHECKDB：

对数据库运行 DBCC CHECKALLOC


对数据库中的每个表和视图运行 DBCC CHECKTABLE


验证数据库中的 Service Broker 数据


对数据库运行 DBCC CHECKCATALOG


验证数据库中每个索引视图的内容


这意味着无需从 DBCC CHECKDB 单独运行 DBCC CHECKALLOC、DBCC CHECKTABLE 或 DBCC CHECKCATALOG。有关所执行检查的更多详细信息，请参阅这些命令的说明。

由于只能以单用户模式访问 Resource 数据库，所以不能直接对其运行 DBCC CHECKDB 命令。但是，当对 master 数据库执行 DBCC CHECKDB 时，也在内部对 Resource 数据库运行另一个 CHECKDB。这意味着 DBCC CHECKDB 可以返回额外结果。当没有设置选项或设置了 PHYSICAL ONLY 或 ESTIMATE ONLY 选项时，该命令返回额外结果集。有关资源数据库的详细信息，请参阅资源数据库。

DBCC CHECKDB 使用内部数据库快照提供必须执行这些检查的事务一致性。有关详细信息，请参阅了解稀疏文件大小和 DBCC (Transact-SQL) 中的“DBCC 内部数据库快照用法”部分。如果无法创建快照或指定了 TABLOCK，DBCC CHECKDB 将获取锁以获得所需一致性。在这种情况下，需要排他数据库锁才能执行分配检查，需要共享表锁才能执行表检查。

注意：
在 SQL Server 2005 中，对 tempdb 运行 DBCC CHECKDB 不会执行任何分配或目录检查，并且必须获取共享表锁才能执行表检查。这是由于为了提高性能，不能对 tempdb 使用数据库快照。这意味着无法获得所需的事务一致性。



如果 DBCC CHECKDB 报告了任何错误，建议从数据库备份还原数据库，而不运行具有一个 REPAIR 选项的 REPAIR。如果不存在备份，则运行修复将更正报告的错误。要使用的修复选项在报告的错误的末尾处指定。但是，通过使用 REPAIR_ALLOW_DATA_LOSS 选项更正错误可能需要删除某些页以及数据。

在某些情况下，可能会在数据库中输入对列的数据类型而言无效或越界的值。在 SQL Server 2000 中，DBCC CHECKDB 不对这些列值执行范围或完整性检查。但是，在 SQL Server 2005 中，DBCC CHECKDB 可以检测到对所有列数据类型都无效的列值。因此，对从 SQL Server 的早期版本升级的数据库运行带 DATA_PURITY 选项的 DBCC CHECKDB 可能会显示预先存在的列值错误。因为 SQL Server 2005 不会自动修复这些错误，所以必须手动更新这些列值。如果 CHECKDB 检测到此类错误，CHECKDB 将返回一个警告、错误号 2570 以及标识受影响的行和手动更正错误的信息。

修复操作可以在用户事务下执行，以使用户回滚所做的更改。如果回滚修复，数据库仍会包含错误，因而必须通过备份进行还原。修复完成后，备份数据库。

默认情况下，DBCC CHECKTABLE 对对象执行并行检查。并行度由查询处理器自动确定。最大并行度的配置与配置并行查询相同。若要限制 DBCC 检查可使用的处理器的最大数目，请使用 sp_configure。有关详细信息，请参阅max degree of parallelism 选项。

通过使用跟踪标志 2528 可以禁用并行检查。有关详细信息，请参阅跟踪标志 (Transact-SQL)。

参数
'database_name' | database_id | 0
要为其运行完整性检查的数据库的名称或 ID。如果未指定，或者指定为 0，则使用当前数据库。数据库名称必须符合标识符规则。

注意：
如果无法创建内部数据库快照，则对 master 运行 DBCC CHECKDB 时将失败。



NOINDEX
指定不应对用户表的非聚集索引执行会占用很大系统开销的检查。这将减少总执行时间。NOINDEX 不影响系统表，因为总是对系统表索引执行完整性检查。

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
指定 DBCC CHECKDB 修复发现的错误。指定的数据库必须处于单用户模式，才能使用以下修复选项之一。

REPAIR_ALLOW_ DATA_LOSS
尝试修复报告的所有错误。这些修复可能会导致一些数据丢失。

REPAIR_FAST
仅为保持向后兼容性而保留。

REPAIR_REBUILD
执行由 REPAIR_FAST 执行的所有修复，包括需要较长时间的修复（如重建索引）。执行这些修复时不会有丢失数据的危险。

注意：
仅将 REPAIR 选项作为最后手段使用。若要修复错误，建议您通过备份进行还原。修复操作不会考虑表本身或表之间可能存在的任何约束。如果指定的表与一个或多个约束有关，建议您在修复操作后运行 DBCC CHECKCONSTRAINTS。如果必须使用 REPAIR，请运行 DBCC CHECKDB 查找要使用的修复级别。如果将使用 REPAIR_ALLOW_DATA_LOSS 级别，建议您在运行 DBCC CHECKDB 之前备份数据库。



WITH
启用要指定的选项。

ALL_ERRORMSGS
显示每个对象不受限制的错误数。如果未指定 ALL_ERRORMSGS，则只显示每个对象前 200 条错误消息。按对象 ID 对错误消息排序，从 tempdb 中生成的那些消息除外。

NO_INFOMSGS
取消所有信息性消息。

TABLOCK
使 DBCC CHECKDB 获取锁，而不使用内部数据库快照。这包括一个短期数据库排他锁。TABLOCK 可使 DBCC CHECKDB 在负荷较重的数据库上运行得更快，但 DBCC CHECKDB 运行时会减少数据库上可获得的并发性。

ESTIMATEONLY
显示估计的 tempdb 空间大小，用于运行带有所有其他指定选项的 DBCC CHECKDB。不执行实际数据库检查。

PHYSICAL_ONLY
将检查限制为页和记录标头的物理结构完整性、B 树的物理结构以及数据库的分配一致性。旨在以较小的开销检查数据库的物理一致性，同时还检测会危及用户数据安全的残缺页、校验和错误和常见的硬件故障。在 SQL Server 2005 中，完整运行 DBCC CHECKDB 所花的时间比早期版本长得多。导致此行为发生的原因如下：

引入的逻辑检查更全面。


要检查的某些基础结构更为复杂。


在 SQL Server 2005 中引入了许多新的检查，以包含新增功能。


因此，在大型数据库上运行 DBCC CHECKDB 时，使用 PHYSICAL_ONLY 选项可以更大程度地缩短运行时间；所以，建议在生产系统中经常使用此选项。还建议定期执行 DBCC CHECKDB 的完整运行。这些运行的执行频率取决于各业务和生产环境特定的因素。PHYSICAL_ONLY 始终表示 NO_INFOMSGS，不能与任何修复选项一同使用。

DATA_PURITY
使 DBCC CHECKDB 检查数据库中是否存在无效或越界的列值。例如，DBCC CHECKDB 检测日期和时间值大于或小于 datetime 数据类型的可接受范围的列，或者小数位数或精度值无效的 decimal 或近似 numeric 数据类型列。

对于在 SQL Server 2005 中创建的数据库，默认情况下将启用列值完整性检查，并且不需要使用 DATA_PURITY 选项。对于从 SQL Server 的早期版本升级的数据库，默认情况下不启用列值检查，直到 DBCC CHECKDB WITH DATA_PURITY 已在数据库中正确运行为止。然后，DBCC CHECKDB 将默认检查列值完整性。有关从 SQL Server 的早期版本升级数据库对 CHECKDB 有何影响的详细信息，请参阅“备注”部分。

如果指定了 PHYSICAL_ONLY，则不执行列完整性检查。

[lansz]

不好听的话就懒得说了

最有效的学习方法永远是先问帮助再问google，实在找不到答案的时候再上论坛灌水

在论坛上面问别人效率低不说，别人告诉你的要不是从帮助上copy，要不就只有只言片语，很多时候误导的成分会更大，对学习不会有太大的帮助

论坛只适合于答疑解惑，用别人的疑问和解答来弥补你经验的不足，根本不适合系统的学习

要明白在这个坛子里面大多数人回帖只是为了赚分，至于答案的质量是不会考虑太多的

[fcuandy]

sql2005仍然提供了dbcc命令对索引碎片处理。

dbcc dbreindex 重建索引
dbcc indexdefrag 整理索引

[水族杰纶]

[Quote=引用楼主 TLJewel 的帖子:]
sql2000里，为了整理碎片，有个DBCC 的方法，在sql2005里是不是被alter index取代了，我想了解下，谁能帮我找下相应的文章，或者帮忙做下简介。

注：让我自己找的就算了，我会自己找的，不过我想尝试新的学习方法，就是在最有效的时间里找到有用的资料，我想应该比我自己找更能发现一些自己没有注意到的事情。
[/Quote]
沒有被取代~~