在 SQL Server 2005 或更高版本中的 DBCC 错误 2570年进行故障排除

文章翻译 文章翻译
文章编号: 923247 - 查看本文应用于的产品
展开全部 | 关闭全部

本文内容

简介

本文介绍了 SQL Server 错误 2570,引起的原因该错误,以及如何解决此问题。

更多信息

DATA_PURITY 检查

在 SQL Server 2005 中,一个新的选项,DATA_PURITY,已添加到DBCC CHECKDB 和聚集的命令。执行 DBCC CHECKDB 时或聚集启用此选项的命令,该命令将执行每个列的值在表中的所有行上的"数据纯度"验证或在数据库中的表。执行这些新的检查,确保存储在列中的值是有效的 (即,值不是超出范围为数据类型的列与相关联的域的)。"执行验证的性质取决于列的数据类型。"后面不完整的列表提供了一些示例:
收起该表格展开该表格
列数据类型执行数据验证的类型
Unicode 字符数据长度应2 的倍数。
日期时间天字段应介于 1753 年 1 月 1年 12 月 31 日和 9999。时间字段必须早于"11:59:59:999 PM"。
实际和浮动检查存在无效的浮点值 (如 SNAN、 QNAN、 NINF,ND、 PD、 PINF。
并不是所有的数据类型的列的有效性检查数据。只是可能有超出了存储的值检查的范围。例如, tinyint 有效范围为 0 到 255 的数据类型,并存储在单字节 (它只能存储从 0 到 255 之间的值),因此检查值没有必要。

未启用数据纯度验证检查自动为所有数据库。具体取决于几个启用检查因素:
  • 对于 SQL Server 2005 或更高版本中创建的数据库,这些检查默认情况下启用,并不能被禁用,因此是不相关的 DATA_PURITY 选项执行 DBCC CHECKDB 或聚集的命令时使用。
  • 对于 SQL 的早期版本中创建的数据库服务器如 SQL Server 2000年、 SQL Server 7.0 和版本升级到 SQL默认情况下未启用服务器 2005 年,这些检查。为了使这些检查要执行,必须指定 DATA_PURITY 选项中的 DBCC CHECKDB 或聚集的命令。这可能会导致两件事:
    • DBCC 命令完成后,报告的数据库没有任何问题,包括所有数据纯度检查。这一事实记录在数据库标头。所有后续的 DBCC CHECKDB 或聚集命令执行将会注意到此信息,将自动执行数据纯度检查,如创建 SQL Server 2005 的数据库发生的情况。在中换句话说,一旦数据库已知"干净"数据纯度检查会始终执行。
    • DBCC 命令完成,但报告有关的问题数据不一致。如果这种情况,必须清除数据库删除不一致,然后尝试再次执行 DBCC 命令。您必须指定 DATA_PURITY 选项,直到 DBCC 命令报告数据库以进行干净。
  • 如果指定了 PHYSICAL_ONLY 选项时 DBCC执行 CHECKDB 或聚集的命令一样,不是数据纯度检查执行。

症状

无效或超出范围的数据可能会被存储在 SQL 中服务器数据库,在早期版本的原因如下:
  • 无效数据时显示在源使用大容量时插入方法例如 bcp 实用工具。
  • 通过对 RPC 事件调用传递了无效的数据SQL Server。
  • 其他可能导致的保留的物理数据损坏列的值处于无效状态。
如果您在表的列中有无效数据,您可能会遇到问题,具体取决于对无效的数据执行的操作的类型。但是,也很可能会出现任何问题,并且直到您在 SQL Server 2005 或更高版本上执行 DBCC CHECKDB 或聚集命令时才会发现无效数据。

一些症状,由于为无效的数据是否存在可能会注意到包括 (但不限于到):
  • 访问冲突或其他类型的异常时正在执行对受影响的列的查询。
  • 对执行的查询所返回的不正确的结果受影响的列。
  • 错误或问题时针对正在生成统计信息受影响的列。
  • 类似于以下错误消息:
    消息9100 级别 23,状态 2 行 1 可能检测到的索引损坏。运行 DBCCCHECKDB。

DATA_PURITY 问题报告

当您执行 DBCC CHECKDB 或聚集的命令启用 DATA_PURITY 选项 (或执行数据纯度检查自动),并由 DBCC 检查的表中存在无效数据命令,DBCC 输出包括其他消息,以表明数据方面的问题。指示数据纯度的一些示例错误消息问题如下所示:
有关 DBCC 结果"account_history"。
消息 2570年,级别 16,状态 2,第 1 行
页 (1:1073),对象 ID 1977058079,索引 ID 0,分区 ID 129568478265344,在插槽 33分配单元 ID 129568478265344 (类型为"行中的数据")。"Account_name_japan"列值超出了范围数据类型"nvarchar"。更新为合法值的列。
消息 2570年,级别 16,状态 2,第 1 行
页 (1:1156),在对象中的插槽 120ID 1977058079、 索引 ID 0,则分区 ID 129568478265344,分配单位 ID129568478265344 (键入"中的行数据")。"Account_name_japan"列中的值是出数据类型"nvarchar"适用的范围。更新为合法值的列。
有是 153137 1080年页对象"account_history"中的行。
找到 CHECKDB0 分配错误和表"account_history"中的 338 一致性错误(对象 ID 1977058079)。
CHECKDB 找到 0 分配错误和 338在数据库中 BadUnicodeData 的一致性错误。
DBCC 执行完毕。如果 DBCC 输出了错误消息,请与您的系统管理员联系。
DBCC"表 1"的结果。
消息 2570 级别16,状态第 3 行 1
页 (1:154)、 对象 ID 2073058421 在插槽 0 中,索引 ID0、 分区 ID 72057594038321152,分配单元 ID 72057594042318848 (类型"行内数据")。"第 2 列"列中的值超出了范围为数据类型的"真实"。更新为合法值的列。
2 个对象的页面中有 4 个行"表 1"。
CHECKDB 找到 0 分配错误和一致性 1 中的错误表"表 1"(对象 ID 2073058421)。
CHECKDB 找到 0 个分配错误并在数据库 'realdata' 1 一致性错误。DBCC 执行完毕。如果DBCC 输出了错误消息,请与系统管理员联系。
DBCC 结果"表 2"。
消息 2570 级别16,状态第 3 行 1
页 (1:155)、 对象 ID 2105058535 在插槽 0 中,索引 ID0、 分区 ID 72057594038452224,分配单元 ID 72057594042449920 (类型"行内数据")。"第 2 列"列中的值超出了范围为数据类型"十进制"。更新为合法值的列。
1 页对象中有 4 个行"表 2"。
CHECKDB 找到 0 分配错误和一致性 1 中的错误表"表 2"(对象 ID 2105058535)。
CHECKDB 找到 0 个分配错误并在数据库 'realdata' 1 一致性错误。DBCC 执行完毕。如果DBCC 输出了错误消息,请与系统管理员联系。
DBCC 予以的结果。
消息 2570 级别16,状态第 3 行 1
页 (1:157)、 对象 ID 2121058592 在插槽 0 中,索引 ID0、 分区 ID 72057594038517760,分配单元 ID 72057594042515456 (类型"行内数据")。"第 2 列"列中的值超出了范围为数据类型"的日期时间"。更新为合法值的列。
1 页对象中有 3 行"予以"。
CHECKDB 找到 0 分配错误和一致性 1 中的错误予以表 (对象 ID 2121058592)。
CHECKDB 找到 0 个分配错误并在数据库 'realdata' 1 一致性错误。DBCC 执行完毕。如果DBCC 输出了错误消息,请与系统管理员联系。
对于生成的每行都包含了无效的列的值 2570年错误。

修复数据纯度问题

使用任何 DBCC 修复无法修复的 2570年错误选项。这是因为很难确定哪些值 DBCC应该用来替换无效的列的值。因此,必须列中的值手动更新。

若要执行手动更新,您必须找到的行有问题。有两种方法可以实现此目的。
  • 对包含的表执行查询若要查找包含无效值的行的值无效。
  • 用于标识从 2570年错误的信息具有无效值的行。
我们将讨论这两种方法中,下面的详细信息使用若要查找包含无效数据的行的示例。

一旦找到正确的行,决定需要对其进行新的值将用于替换现有的数据无效。这一决定必须进行时应非常谨慎根据应用程序处理的值的范围,以及什么逻辑意义的对应行的数据。您可以的选择是:
  • 如果您知道它应该是什么值,则将其设置为的特定的值。
  • 将其设置为可接受默认值。
  • 将列的值设置为 NULL。
  • 将列的值设置为最大值或最小值列的该数据类型。
  • 如果您觉得使用,无需任何不是特定行有效的值的列,则可以删除该行完全。

查找具有使用 T SQL 查询无效值的行

要执行的查找行所需的查询类型无效的值取决于报告问题的列的数据类型。如果您看一下 2570年错误消息,您会注意到两个重要的这将帮助您的信息。在以下示例中,列"account_name_japan"值超出了范围数据类型"nvarchar"。我们可以轻松地识别有问题,以及数据类型的列所涉及的列。因此,一旦您知道数据类型和涉及到的列,您可以创建查询以查找包含无效值的行列中,选择所需标识该行 (作为谓词中的列WHERE 子句) 的任何进一步更新或删除。

Unicode 数据类型:
SELECT col1 ,DATALENGTH(account_name_japan) as Length ,account_name_japan 
FROM account_history
WHERE DATALENGTH(account_name_japan) % 2 != 0

浮点型数据类型:
-- Change col1 to your actual primary key column(s), col2 to the column from the 2570 error, table1 to the table from the CHECKDB output

SELECT col1, col2 FROM table1
WHERE col2<>0.0 AND (col2 < 2.23E-308 OR col2 > 1.79E+308) AND (col2 < -1.79E+308 OR col2 > -2.23E-308)

真正的数据类型:
-- Change col1 to your actual primary key column(s), col2 to the column from the 2570 error, table1 to the table from -- the CHECKDB output

SELECT col1, col2 FROM testReal 
WHERE col2<>0.0 AND (col2 < CONVERT(real,1.18E-38) OR col2 > CONVERT(real,3.40E+38)) AND (col2 < CONVERT(real,-3.40E+38) OR col2 > CONVERT(real,-1.18E-38)) 
ORDER BY col1; -- checks for real out of range
十进制和数字数据类型:
SELECT col1 FROM table2
WHERE col2 > 9999999999.99999 
OR col1 < -9999999999.99999
请记住,您需要调整基于值精度和与您定义的十进制或数字列的小数位数。在上面的示例中,将第 2 列 decimal(15,5) 作为定义列。

日期时间数据类型:
您将需要执行两个不同的查询来识别包含无效的日期时间列的值的行。
SELECT col1 FROM table3
WHERE col2 < '1/1/1753 12:00:00 AM' OR col2 > '12/31/9999 11:59:59 PM'

SELECT col1 FROM table3 WHERE
((DATEPART(ms,col2)+ (1000*DATEPART(s,col2)) + (1000*60*DATEPART(mi,col2)) + (1000*60*60*DATEPART(hh,col2)))/(1000*0.00333)) 
> 25919999

查找使用的物理位置的无效值的行:

如果您找不到的行,您可以使用此方法使用上面讨论的 T SQL 方法感兴趣。在 2570年错误消息中,打印包含无效值的行的物理位置。对于示例中,看看下面的消息:
页 (1:157),对象 ID 2121058592,索引 ID 0,分区 ID 72057594038517760,在插槽 0分配单元 ID 72057594042515456 (类型为"行中的数据")。"第 2 列"列中的值是超出范围数据类型"的日期时间"。更新列法律值。
在此邮件中,您会注意到的信息: 页面 (1:157),插槽 0 中。这是标识行所需的信息。FileId 为 1,PageInFile 是 157,和 SlotId 为 0。一旦您知道此信息,您需要执行该命令,如下所示:
DBCC TRACEON ( 3604 )
DBCC PAGE ( realdata , 1 , 157 , 3 )
此命令将打印页面的全部内容。参数DBCC 页命令是:
  • 数据库名称
  • FileId
  • PageInFile
  • 打印选项
一旦执行此命令,您会注意到的输出包含的信息类似于以下格式:
Slot 0 Offset 0x60 Length 19 Record Type = PRIMARY_RECORD Record
		  Attributes = NULL_BITMAP Memory Dump @0x44D1C060 00000000: 10001000 01000000
		  ffffffff ffffffff ?................ 00000010:
		  0200fc???????????????????????????????... Slot 0 Column 0 Offset 0x4 Length 4 col1 = 1Slot 0 Column 1 Offset 0x8 Length 8 col2 = Dec 31 1899 19:04PM Slot 1 Offset 0x73 Length 19 Record Type = PRIMARY_RECORD Record
		  Attributes = NULL_BITMAP Memory Dump @0x44D1C073 00000000: 10001000 02000000
		  0ba96301 f8970000 ?..........c..... 00000010:
		  0200fc???????????????????????????????... Slot 1 Column 0 Offset 0x4 Length 4
		  col1 = 2 Slot 1 Column 1 Offset 0x8 Length 8 col2 = Jul 8 2006 9:34PM Slot 2
		  Offset 0x86 Length 19 Record Type = PRIMARY_RECORD Record Attributes =
		  NULL_BITMAP Memory Dump @0x44D1C086 00000000: 10001000 03000000 0ba96301
		  f8970000 ?..........c..... 00000010: 0200fc???????????????????????????????...
		  Slot 2 Column 0 Offset 0x4 Length 4 col1 = 3 Slot 2 Column 1 Offset 0x8 Length
		  8 col2 = Jul 8 2006 9:34PM 
您可以在此输出中清楚地看到您感兴趣的行的列值。在这种情况下,您需要存储在页的插槽 0 中的行。从该错误消息,您知道该第 2 列是一个问题。因此,您可以采取的第 1 列的值插槽 0,并将其用作您的更新语句的 WHERE 子句中的谓词或删除语句。

警告 我们建议您使用第一种方法 (即,使用 T-SQL查询以查找所需的信息)。使用页面 DBCC 命令只能作为最后的手段。在生产环境中使用此命令时请携带方便的注意环境。建议恢复生产数据库上测试服务器,然后获取所有使用 DBCC 页,所需的信息,然后执行在生产服务器上的更新。与以往一样,确保保留备份准备万一出现故障并需要恢复到先前的副本数据库。

参考

有关 DBCC CHECKDB 语句的详细信息,请参阅在下面的 Microsoft 开发人员"DBCC CHECKDB (? ° SQL)"主题网络 (MSDN) 的 Web 站点:
http://msdn2.microsoft.com/en-us/library/ms176064.aspx
有关已知详细信息问题在 SQL Server 2000 中,单击下面的文章编号,以查看Microsoft 知识库中相应的文章:
900335修复: SQL Server 2000年数据库自动恢复操作可能会失败如果索引包含浮点型数据类型或真正的数据类型,并且此数据类型包含 NaN 值
有关 RPC 事件的详细信息,请参阅在下面的 MSDN Web 站点上的"调用存储过程 (OLE DB)"主题:
http://msdn2.microsoft.com/en-us/library/aa198358 (SQL.80).aspx
有关不同数据类型的详细信息,请参阅在下面的 MSDN Web 站点上的"调用存储过程 (OLE DB)"主题:
http://msdn2.microsoft.com/en-us/library/ms187752.aspx
有关浮动点值约定的详细信息,请访问以下英特尔网站:
http://www.intel.com/design/pentiumii/manuals/243191.htm
Microsoft提供第三方联系信息以帮助您查找技术支持。此联系信息如有更改恕不另行通知。Microsoft 没有保证此第三方联系信息的准确性。

属性

文章编号: 923247 - 最后修改: 2012年3月22日 - 修订: 1.0
这篇文章中的信息适用于:
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL 2005 Server Enterprise
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Express Edition with Advanced Services
  • Microsoft SQL 2005 Server Workgroup
  • Microsoft SQL Server 2005 Enterprise Edition for Itanium Based Systems
  • Microsoft SQL Server 2005 Enterprise X64 Edition
  • Microsoft SQL Server 2005 Standard Edition for Itanium Based Systems
  • Microsoft SQL Server 2005 Standard X64 Edition
  • Microsoft SQL Server 2008 Standard
  • Microsoft SQL Server 2008 R2 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Express with Advanced Services
  • Microsoft SQL Server 2008 Workgroup
  • Microsoft SQL Server 2008 Standard Edition for Small Business
关键字:?
kbtshoot kbexpertiseadvanced kbsql2005engine kbinfo kbmt KB923247 KbMtzh
机器翻译
注意:这篇文章是由无人工介入的微软自动的机器翻译软件翻译完成。微软很高兴能同时提供给您由人工翻译的和由机器翻译的文章, 以使您能使用您的语言访问所有的知识库文章。然而由机器翻译的文章并不总是完美的。它可能存在词汇,语法或文法的问题,就像是一个外国人在说中文时总是可能犯这样的错误。虽然我们经常升级机器翻译软件以提高翻译质量,但是我们不保证机器翻译的正确度,也不对由于内容的误译或者客户对它的错误使用所引起的任何直接的, 或间接的可能的问题负责。
点击这里察看该文章的英文版: 923247
Microsoft和/或其各供应商对于为任何目的而在本服务器上发布的文件及有关图形所含信息的适用性,不作任何声明。 所有该等文件及有关图形均"依样"提供,而不带任何性质的保证。Microsoft和/或其各供应商特此声明,对所有与该等信息有关的保证和条件不负任何责任,该等保证和条件包括关于适销性、符合特定用途、所有权和非侵权的所有默示保证和条件。在任何情况下,在由于使用或运行本服务器上的信息所引起的或与该等使用或运行有关的诉讼中,Microsoft和/或其各供应商就因丧失使用、数据或利润所导致的任何特别的、间接的、衍生性的损害或任何因使用而丧失所导致的之损害、数据或利润不负任何责任。

提供反馈

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com