34,587
社区成员
发帖
与我相关
我的任务
分享请教：在程序中使用到一个查询的时候突然出现“SQL 605 致命错误”是怎么回事？
其他地方在涉及到这个几个表的查询都没有问题，昨天用的都还很正常的。应该如何排错？
我用的SQLSERVER2000
我用的SQLSERVER2000
...全文
请发表友善的回复…
发表回复
lxl 2003-12-03
- 打赏
- 举报
没人啦？大家吃FF去了？55555，我一人在这时挨饿
lxl 2003-12-03
- 打赏
- 举报
我已经看过帮助了，
但困惑的是如果是数据库损坏
可是为什么我的数据库程序的其他菜单项在访问同一个表时就没有出现这样的提示呢？
但困惑的是如果是数据库损坏
可是为什么我的数据库程序的其他菜单项在访问同一个表时就没有出现这样的提示呢？
CrazyFor 2003-12-03
- 打赏
- 举报
Transact-SQL 参考
DBCC
Transact-SQL 编程语言提供 DBCC 语句作为 Microsoft® SQL Server™ 2000 的数据库控制台命令。这些语句对数据库的物理和逻辑一致性进行检查。许多 DBCC 语句能够对检测到的问题进行修复。
数据库控制台命令语句被分为以下类别。
语句分类 执行
维护语句 对数据库、索引或文件组进行维护的任务。
杂项语句 诸如启用行级锁定或从内存中删除动态链接库 (DLL) 等杂项任务。
状态语句 状态检查。
验证语句 对数据库、表、索引、目录、文件组、系统表或数据库页的分配进行的验证操作。
SQL Server 2000 的 DBCC 语句使用输入参数和返回值。所有 DBCC 语句参数都可以接受 Unicode 和 DBCS 字面值。
使用 DBCC 结果集输出
许多 DBCC 命令可以产生表格格式的输出（使用 WITH TABLERESULTS 选项）。该信息可装载到表中以便将来使用。以下显示一个示例脚本：
-- Create the table to accept the results
CREATE TABLE #tracestatus (
TraceFlag INT,
Status INT
)
-- Execute the command, putting the results in the table
INSERT INTO #tracestatus
EXEC ('DBCC TRACESTATUS (-1) WITH NO_INFOMSGS')
-- Display the results
SELECT *
FROM #tracestatus
GO
维护语句
DBCC DBREINDEX
DBCC DBREPAIR
DBCC INDEXDEFRAG
DBCC SHRINKDATABASE
DBCC SHRINKFILE
DBCC UPDATEUSAGE
杂项语句
DBCC dllname (FREE)
DBCC HELP
DBCC PINTABLE
DBCC ROWLOCK
DBCC TRACEOFF
DBCC TRACEON
DBCC UNPINTABLE
状态语句
DBCC PINTABLE
DBCC OPENTRAN
DBCC OUTPUTBUFFER
DBCC PROCCACHE
DBCC SHOWCONTIG
DBCC SHOW_STATISTICS
DBCC SQLPERF
DBCC TRACESTATUS
DBCC USEROPTIONS
验证语句
DBCC CHECKALLOC
DBCC CHECKCATALOG
DBCC CHECKCONSTRAINTS
DBCC CHECKDB
DBCC CHECKFILEGROUP
DBCC CHECKIDENT
DBCC CHECKTABLE
DBCC NEWALLOC
©1988-2000 Microsoft Corporation。保留所有权利。
DBCC
Transact-SQL 编程语言提供 DBCC 语句作为 Microsoft® SQL Server™ 2000 的数据库控制台命令。这些语句对数据库的物理和逻辑一致性进行检查。许多 DBCC 语句能够对检测到的问题进行修复。
数据库控制台命令语句被分为以下类别。
语句分类 执行
维护语句 对数据库、索引或文件组进行维护的任务。
杂项语句 诸如启用行级锁定或从内存中删除动态链接库 (DLL) 等杂项任务。
状态语句 状态检查。
验证语句 对数据库、表、索引、目录、文件组、系统表或数据库页的分配进行的验证操作。
SQL Server 2000 的 DBCC 语句使用输入参数和返回值。所有 DBCC 语句参数都可以接受 Unicode 和 DBCS 字面值。
使用 DBCC 结果集输出
许多 DBCC 命令可以产生表格格式的输出（使用 WITH TABLERESULTS 选项）。该信息可装载到表中以便将来使用。以下显示一个示例脚本：
-- Create the table to accept the results
CREATE TABLE #tracestatus (
TraceFlag INT,
Status INT
)
-- Execute the command, putting the results in the table
INSERT INTO #tracestatus
EXEC ('DBCC TRACESTATUS (-1) WITH NO_INFOMSGS')
-- Display the results
SELECT *
FROM #tracestatus
GO
维护语句
DBCC DBREINDEX
DBCC DBREPAIR
DBCC INDEXDEFRAG
DBCC SHRINKDATABASE
DBCC SHRINKFILE
DBCC UPDATEUSAGE
杂项语句
DBCC dllname (FREE)
DBCC HELP
DBCC PINTABLE
DBCC ROWLOCK
DBCC TRACEOFF
DBCC TRACEON
DBCC UNPINTABLE
状态语句
DBCC PINTABLE
DBCC OPENTRAN
DBCC OUTPUTBUFFER
DBCC PROCCACHE
DBCC SHOWCONTIG
DBCC SHOW_STATISTICS
DBCC SQLPERF
DBCC TRACESTATUS
DBCC USEROPTIONS
验证语句
DBCC CHECKALLOC
DBCC CHECKCATALOG
DBCC CHECKCONSTRAINTS
DBCC CHECKDB
DBCC CHECKFILEGROUP
DBCC CHECKIDENT
DBCC CHECKTABLE
DBCC NEWALLOC
©1988-2000 Microsoft Corporation。保留所有权利。
lvltt 2003-12-03
- 打赏
- 举报
Select * from master..sysmessages where error =错误号 605 具体看description
sysmessages
每个可由 Microsoft® SQL Server™ 返回的系统错误和警告分别占一行。SQL Server 在用户的屏幕上显示对错误的描述。
列名 数据类型 描述
error int 唯一错误号。
severity smallint 错误的严重级别。
dlevel smallint 仅限内部使用。
description nvarchar(255) 对参数占位符错误的解释。
mslangid smallint 系统消息组 ID。
sysmessages
每个可由 Microsoft® SQL Server™ 返回的系统错误和警告分别占一行。SQL Server 在用户的屏幕上显示对错误的描述。
列名 数据类型 描述
error int 唯一错误号。
severity smallint 错误的严重级别。
dlevel smallint 仅限内部使用。
description nvarchar(255) 对参数占位符错误的解释。
mslangid smallint 系统消息组 ID。
CSDNM 2003-12-03
- 打赏
- 举报
帮助很清楚了
CSDNM 2003-12-03
- 打赏
- 举报
先看看帮助：
错误 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 更快。这是确信数据库在备份时的状态的唯一方法。
如果数据十分重要，则经常备份事务日志。这可以将脆弱性时段减小到一个小时或更短，即使是在发生灾难性硬件问题的情况下。
在大多数重要情况下，使用备用服务器和连续运行的批处理作业从主计算机移走事务备份，并在备用计算机上连续进行还原。
如果不停地遇到数据损失问题，尝试将计算机、控制器和磁盘设备驱动程序交换为不同类型的组件。以便更容易地确定问题是否与特定的平台有关。
错误 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 更快。这是确信数据库在备份时的状态的唯一方法。
如果数据十分重要，则经常备份事务日志。这可以将脆弱性时段减小到一个小时或更短，即使是在发生灾难性硬件问题的情况下。
在大多数重要情况下，使用备用服务器和连续运行的批处理作业从主计算机移走事务备份，并在备用计算机上连续进行还原。
如果不停地遇到数据损失问题，尝试将计算机、控制器和磁盘设备驱动程序交换为不同类型的组件。以便更容易地确定问题是否与特定的平台有关。
lxl 2003-12-03
- 打赏
- 举报
这种情况是不是
使用以下命令就可以了？客户不在本地，请有经验的朋友帮忙
DBCC CHECKDB ('数据库名', [REPAIR_REBUILD])
使用以下命令就可以了？客户不在本地，请有经验的朋友帮忙
DBCC CHECKDB ('数据库名', [REPAIR_REBUILD])
lxl 2003-12-03
- 打赏
- 举报
再请教：
运行了CHECKDB后提示
发现了 0 个分配错误和 3 个一致性错误
这种情况如何处理，最好不要丢失数据
运行了CHECKDB后提示
发现了 0 个分配错误和 3 个一致性错误
这种情况如何处理，最好不要丢失数据
nik_Amis 2003-12-03
- 打赏
- 举报
up
lxl 2003-12-03
- 打赏
- 举报
又UP 一次，没人知道么？
