SQL困难

Question

新建SQL索引的时候提示下面错我：
服务器：消息 605,级别21,状态1
试图从数据库'rx' 中提取的逻辑页(1:122606)属于对象'834102012',而非对象'T_JXC'

Answer 1

赶紧查查你的数据库!
错误 605
严重级别 21
消息正文
试图从数据库 ''%2!'' 中提取的逻辑页 %1! 属于对象 ''%4!''，而非对象 ''%6!''。解释
当 Microsoft® SQL Server™ 检测到数据库损坏时发生该错误。在文本而非对象 ''%6!'' 中指定的第二个对象可能损坏。因为该错误可以屏蔽其它错误的存在，所以请执行 DBCC CHECKDB 以确定损坏的程度。如果 DBCC CHECKDB 未报告其它错误，则提到的第一个对象未损坏。当 SQL Server 遍历某对象的页并在链中找到其对象 ID 与被访问对象的 ID 不匹配的页时检测到数据库损坏。可能存在已损坏的页链、损坏的索引分配映射表 (IAM) 或 sysobjects 系统表中该对象的无效条目。聚集表具有一个表数据的双向链接的页链，每个索引级别也具有一个双向链接的页链。非聚集索引的每个索引级别具有一个页链。堆集中的页未链接。IAM 用于查找堆集的页。尽管错误 605 通常显示两个对象名，但可以发生其它的变化： 如果错误未显示对象名而显示大于 0 的数字，则表示试图引用该对象的系统表中不存在的对象 ID。
如果错误报告第一个对象 ID 为 0，则可能遇到了一个未分配页。（不存在等于 0 的对象 ID。）
如果错误指出属于对象 ALLOCATION 的页，则数据库使用的某些分配结构可能损坏了。 
通常该错误在损坏已写入磁盘上的数据库之后发生，但它还可以在损坏尚未写入磁盘的情况下完全在高速缓存中发生。这称为暂时的 605 错误，且不与数据损坏相关联。如果错误 605 在数据访问期间发生，但后续的 DBCC CHECKDB 语句在没有出错的情况下完成，则 605 错误可能是暂时的。暂时的 605 错误可以由操作系统过早地通知 SQL Server 已完成某个 I/O 操作而引起；尽管不存在实际的数据损坏，但显示错误信息。非暂时的 605 错误通常由硬件或磁盘设备驱动程序失败而引起。对策
在错误信息中指定的第二个对象上执行 DBCC CHECKTABLE。若要确定损坏的完全程度，请尽快执行 DBCC CHECKDB。同时检查错误日志以确定是否有其它错误，经常有错误伴随 605 错误。如果 605 错误不是暂时的，则问题很严重，必须运行带有一个修复子句的 DBCC CHECKDB。如果错误涉及索引页，请使用 REPAIR_REBUILD 子句。如果错误涉及数据页，可能需要使用 REPAIR_ALLOW_DATA_LOSS 子句。在不允许丢失数据的可能事件中，将需要从已知的干净备份进行还原。如果问题仍然存在，请与您的主要支持提供者联系。使 DBCC CHECKDB 的输出可查阅。重要  如果运行带有一个修复子句的 DBCC CHECKDB 未更正索引问题，或不确定带有修复子句的 DBCC CHECKDB 对数据有何影响，则请与您的主要支持提供者联系。
此外，运行硬件诊断并更正问题。您可能发现在计算机上执行全新的安装（包括重新格式化磁盘驱动器和重新安装操作系统）十分有益。这消除了 .dll 或 .exe 程序损坏的可能性。还可以检查操作系统错误日志以查看错误的发生是否是硬件故障的结果。最后，确保系统未在磁盘控制器上启用写入缓存。如果怀疑这是问题起因，请与您的硬件供应商联系。其它信息
DBCC CHECKDB 提供 REPAIR_REBUILD 和 REPAIR_ALLOW_DATA_LOSS 子句。REPAIR_REBUILD 子句重建损坏的索引，而 REPAIR_ALLOW_DATA_LOSS 子句修复分配问题。有时，删除页是修复分配问题的唯一方法。通常，这些页包含已删除的数据，但它们可能包含有效数据。因此，删除页比使用带有修复子句的 DBCC CHECKDB 更危险。当无可用的数据库备份时使用带有修复子句的 DBCC CHECKDB 修复数据库损坏。如果您的数据库是数据仓库，则可以在重新加载丢失的数据之前在没有所丢失数据的情况下继续操作一段时间。在这些情况下，使用带有 REPAIR_ALLOW_DATA_LOSS 子句的 DBCC CHECKDB 修复已损坏的数据库。可以通过遵照下列准则来防止问题： 只在针对您的操作系统已验证的硬件和控制器中运行 SQL Server。
同 DBCC CHECKDB 语句一起执行常规备份。DBCC CHECKDB 执行 DBCC NEWALLOC 和 DBCC CHECKALLOC 以前执行的所有检查，但 DBCC CHECKDB 更快。这是确信数据库在备份时的状态的唯一方法。
如果数据十分重要，则经常备份事务日志。这可以将脆弱性时段减小到一个小时或更短，即使是在发生灾难性硬件问题的情况下。
在大多数重要情况下，使用备用服务器和连续运行的批处理作业从主计算机移走事务备份，并在备用计算机上连续进行还原。
如果不停地遇到数据损失问题，尝试将计算机、控制器和磁盘设备驱动程序交换为不同类型的组件。以便更容易地确定问题是否与特定的平台有关。