sql2005数据库错误修复

[hnhslwl]

sql2005sp2数据错误.
使用DBCC CheckDB 报错信息如下:
消息 605，级别 12，状态 3，第 1 行
尝试在数据库 21 中提取逻辑页 (1:123520) 失败。该逻辑页属于分配单元 -9223371538631032832，而非 281474979397632。
消息 8921，级别 16，状态 1，第 1 行
检查已终止。收集事实数据时检测到错误。可能是 tempdb 空间用尽或某个系统表不一致。请检查前面的错误消息。

不知如何修复数据库.请多给意见.

[飘零一叶]

疑难解答   

  
错误   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   更快。这是确信数据库在备份时的状态的唯一方法。 


如果数据十分重要，则经常备份事务日志。这可以将脆弱性时段减小到一个小时或更短，即使是在发生灾难性硬件问题的情况下。 


在大多数重要情况下，使用备用服务器和连续运行的批处理作业从主计算机移走事务备份，并在备用计算机上连续进行还原。 


如果不停地遇到数据损失问题，尝试将计算机、控制器和磁盘设备驱动程序交换为不同类型的组件。以便更容易地确定问题是否与特定的平台有关。   

请参见 

备份和还原数据库 

BACKUP 

错误   1   -   999 

管理对象使用的空间 

将错误报告给您的主要支持提供者 

使用备用服务器 

©1988-2000   Microsoft   Corporation。保留所有权利。

[王向飞]

ALTER DATABASE dbname SET SINGLE_USER

DBCC CHECKDB('db_name', REPAIR_REBUILD)

[ycproc]

修复 还不如 干脆 卸载了 重装

[飘零一叶]

use master 
declare @databasename varchar(255) 
set @databasename='需要修复的数据库实体的名称' 
exec sp_dboption @databasename, N'single', N'true' --将目标数据库置为单用户状态 
dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS) 
dbcc checkdb(@databasename,REPAIR_REBUILD) 
exec sp_dboption @databasename, N'single', N'false'--将目标数据库置为多用户状态