下面，我们来举一个例子说明SQL Server 2000的修复实践。
ALTER DATABASE POS_DB SET SINGL_USER
GO
DBCC CHECKDB('POS_DB',repair_allow_data_loss) WITH TABLOCK
GO
ALTER DATABASE POS_DB SET MULTI_USER
GO
CHECKDB 有3个参数:
REPAIR_ALLOW_DATA_LOSS
执行由 REPAIR_REBUILD 完成的所有修复，包括对行和页进行分配和取消分配以改正分配错误、结构行或页的错误，以及删除已损坏的文本对象。这些修复可能会导致一些数据丢失。修复操作可以在用户事务下完成以允许用户回滚所做的更改。如果回滚修复，则数据库仍会含有错误，应该从备份进行恢复。如果由于所提供修复等级的缘故遗漏某个错误的修复，则将遗漏任何取决于该修复的修复。修复完成后，备份数据库。
REPAIR_FAST 进行小的、不耗时的修复操作，如修复非聚集索引中的附加键。这些修复可以很快完成，并且不会有丢失数据的危险。
REPAIR_REBUILD 执行由 REPAIR_FAST 完成的所有修复，包括需要较长时间的修复（如重建索引）。执行这些修复时不会有丢失数据的危险。
PHYSICAL_ONLY
仅限于检查页和记录标题物理结构的完整性，以及页对象 ID 和索引 ID 与分配结构之间的一致性。该检查旨在以较低的开销检查数据库的物理一致性，同时还检测会危及用户数据安全的残缺页和常见的硬件故障。PHYSICAL_ONLY 始终意味着 NO_INFOMSGS，并且不能与任何修复选项一起使用。
1.RAID5并不能保证SQLSERVER 2000 数据库的数据文件的完整性；
2.SQLERVER 2000的备份程序不验证数据库文件的数据完整性；如果你的数据文件有问题，备份时也不图示；
3.DBCC CHECKDB的repair_allow_data_loss并不是非常安全的，不能修复所有的错误，即使是对不完整页（TORN PAGE）的修复也会着成数据丢失；
4.DBCC CHECKDB的REPAIR_ALLOW_DATA_LOSS参数无法修复所有的错误