|
错误602：未能在sysindexes中找到数据库ID 13 中对象ID 1对应的行,请对sysindexes 运行OBCC CHECKTABLE” 原因1 2005的数据库附加到2000数据库上了 解决方案：因为数据库附加到2005的时候, 数据库文件已经自动升级到2005, 所以在2000下是无法再附加的(没有向上兼容的)直接restore或附加是不行的, 用脚本+导数据肯定没有问题。 2005转到2000的步骤步骤 1. 生成for 2000版本的数据库脚本 2005 的manger studio -- 打开"对象资源管理器"(没有的话按F8), 连接到你的实例 -- 右键要转到2000的库 -- 任务 -- 生成脚本 -- 在"脚本向导"的"选择数据库"中, 确定选择的是要转到2000的库 -- 勾选"为所选数据库中的所有对象编写脚本" -- 在接下来的"选择脚本选项"中, 找到"为服务器版本编写脚本"项, 选择"SQL Server 2000" -- 其他选项根据需要设置 -- 最后把脚本保存到一个 .sql 脚本文件 2. 在2000中创建目标数据库 在查询分析器(或2005的manger studio在打开脚本文件), 连接到SQL Server 2000,执行上面生成的脚本.以创建一个新的数据库 3. 将数据从2005导到2000 2005 的manger studio -- 打开"对象资源管理器"(没有的话按F8), 连接到你的实例 -- 右键要转到2000的库 -- 任务 -- 导出数据 -- 在"SQL Server 导入和导出向导"的"选择数据源"步骤中, 确定选择的是要导出的数 据库 -- 在"选择目标"步骤中, 连接到 2000, 并选择步骤2新建的库 -- 在"选择源表和源视图"中, 选择所有的表 -- 最后完成 另类： 先装的2000 又装2005导入2005数据库就有这样的问题 直接装2005导入就没问题. ========================================= DBCC CHECKTABLE 语法： DBCCCHECKTABLE('table_name'|'view_name'[,{NOINDEX|index_id}|,{REPAIR_ALLOW_DATA_LOSS|REPAIR_FAST|REPAIR_REBUILD}])[WITH{ALL_ERRORMSGS][,NO_INFOMSGS][,TABLOCK][,ESTIMATEONLY][,{PHYSICAL_ONLY|DATA_PURITY}]}] 参数： NOINDEX 指定不应对用户表的非聚集索引执行会占用很大系统开销的检查。这将减少总执行时间。NOINDEX 不会影响系统表，因为完整性检查的执行对象始终是所有系统表索引。 index_id 要进行完整性检查的索引标识 (ID) 号。如果指定了 index_id，则 DBCC CHECKTABLE 只对该索引以及堆或聚集索引执行完整性检查。 REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD 指定 DBCC CHECKTABLE 修复发现的错误。若要使用修复选项，数据库必须处于单用户模式。 REPAIR_ALLOW_DATA_LOSS (最严格的修复方法，会修复所有的索引，还会重建数据页的存储分配和指针，并且还会从数据页中删去残缺的数据。 ) 尝试修复报告的所有错误。这些修复可能会导致一些数据丢失。 REPAIR_FAST (最简单的修复模式，只修得非聚集索引的键，不会对数据页进行操作。) 保留语法只是为了向后兼容。未执行修复操作。 REPAIR_REBUILD (中等级别的修复方法，对于所有的非聚集索引和索引指针进行完全的检查和重建。不会对数据页进行写入操作。) 既执行次要且不耗时的修复操作（如修复非聚集索引中的额外关键字），也执行耗时的修复操作（如重建索引）。执行这些修复时不会有丢失数据的危险。 ALL_ERRORMSGS 显示不受限制的错误数。如果未指定 ALL_ERRORMSGS，则只显示前 200 个错误消息。 NO_INFOMSGS 取消显示所有信息性消息。 TABLOCK 可使 DBCC CHECKTABLE 获得一个共享表锁，而不使用内部数据库快照。TABLOCK 可使 DBCC CHECKTABLE 在负荷较重的表上运行得更快，但 DBCC CHECKTABLE 运行时会减少表上可获得的并发性。 ESTIMATEONLY 显示运行 DBCC CHECKTABLE 和所有其他指定选项时，所需的 tempdb 空间的估计大小。 PHYSICAL_ONLY 限制为检查页、记录标头的物理结构以及 B 树物理结构的完整性。此选项旨在以较低的开销检查表的物理一致性，同时，此项检查还可以检测可能危及用户数据安全的残缺页和常见的硬件故障。在 SQL Server 2005 中，DBCC CHECKTABLE 完整运行的时间可能比早期版本要长得多。导致此行为发生的原因如下： 逻辑检查比较全面。 要检查的某些基础结构更为复杂。 在 SQL Server 2005 中引入了许多新的检查，以包含新增功能。 因此，使用 PHYSICAL_ONLY 选项可能会使 DBCC CHECKTABLE 在大型表上运行的时间短得多，所以对需要频繁检查的生产系统，建议使用 DBCC CHECKTABLE。我们仍然建议定期执行 DBCC CHECKTABLE 的完整运行。这些运行的执行频率取决于各业务和生产环境特定的因素。PHYSICAL_ONLY 始终表示 NO_INFOMSGS，不能与任何修复选项一同使用。 DATA_PURITY 使 DBCC CHECKTABLE 检查表中是否存在无效或越界的列值。例如，DBCC CHECKTABLE 检测到日期和时间值大于或小于 datetime 数据类型的可接受范围的列，或者小数位数或精度值无效的 decimal 或近似 numeric 数据类型列。 对于在 SQL Server 2005 中创建的数据库，默认情况下将启用列值完整性检查，并且不需要使用 DATA_PURITY 选项。对于从 SQL Server 的早期版本升级的数据库，您可以使用 DBCC CHECKTABLE WITH DATA_PURITY 查找和更正特定表中的错误，但是默认情况下不会对该表启用列值检查，直到 DBCC CHECKDB WITH DATA_PURITY 在数据库中正确运行时为止。然后，DBCC CHECKDB 和 DBCC CHECKTABLE 将默认检查列值完整性 (责任编辑：admin) |