none
LDB数据类型节点的数据库ID6,页(3:1557398),槽3不存在。这通常是由于可以读取数据页上为调教的数据的事务所致的 RRS feed

  • 问题

  • 最近我们的数据库服务器意外断电,数据库版本为SQL Server 2005sp2,导致了备份失败,找到如下报错:LDB数据类型节点的数据库ID6,页(3:1557398),槽3不存在。这通常是由于可以读取数据页上为调教的数据的事务所致的,请运行DBCC Checktable。
    想请问:

    1.这个问题的发生是一次偶然吗?还是说服务器意外关机通常都会导致这样的问题,过往的关机或重启并没有让我们遇到这个报错。
    2.页(3:1557398):如何通过这个信息定位到具体数据页或表?
    3.有搜索到通过以下命令修复:是否可行,“repair_allow_data_loss”的数据丢失机制是怎样的?
    use master  
    exec sp_dboption 'dbTemp', 'single', 'true' 
    dbcc checkdb('dbTemp',repair_allow_data_loss);  
    dbcc checkdb('dbTemp',repair_rebuild);  
    exec sp_dboption 'dbTemp', 'single', 'false' 

    2020年6月7日 23:26

答案

  • 你好,

    为了诊断问题出现的地方,你可以用以下方法:

    1.用DBCC CHECKDB\DBCC CHECKTABLES

    2.在不运行DBCC CHECKDB的情况下查找表中错误的确切位置, 您将需要查找在查询搜索期间使用的表。

    3.您也可以使用“ SQL事件探查器( SQL Profiler)”在查询中查找确切的问题。

    你可以参考这篇文章:How to troubleshoot Msg 7105 in SQL Server

    除此之外,你也可以用DBCC PAGE查询表和索引数据:利用DBCC PAGE查看SQL Server中的表和索引数据

    SQL Server: How to find Table name from Page ID?

    SELECT * FROM [msdb].[dbo].[suspect_pages];  --查找有问题的数据库ID,文件ID和页码
    go
    
    DBCC TRACEON (3604);
    DBCC Page (6,3,1557398);   --根据你的报错信息,数据库ID是6,文件ID是3,页码是1557398
    DBCC TRACEOFF (3604);
    go
    
    SELECT OBJECT_NAME (ObjectId);  --查看有问题的元数据
    go



    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.


    2020年6月8日 9:05

全部回复

  • 你好,

    你这个报错信息的主要原因有三点:

    1.数据库页面内或LOB页面结构中存在数据库损坏问题,数据库页面引用
    2.遇到故障的查询正在使用READ UNCOMMITTED ISOLATION LEVEL或NOLOCK查询提示
    3.SQL Server Engine中存在问题,导致查询因该错误而失败。

    根据你的描述,是意外断电引起的,也就是极有可能数据库有未提交的事务,导致了数据的损坏:

    针对你的问题,做如下回复:

    》》1.这个问题的发生是一次偶然吗?还是说服务器意外关机通常都会导致这样的问题,过往的关机或重启并没有让我们遇到这个报错。

    这个问题的发生是偶然的,但是也是有较大概论发生的

    》》2.页(3:1557398):如何通过这个信息定位到具体数据页或表?

    请使用DBCC CHECKTABLE (Transact-SQL) 检查组成表或索引视图的所有页和结构的完整性,从而定位出损坏的页或表。

    DBCC CHECKTABLE     
    (    
        table_name | view_name    
        [ , { NOINDEX | index_id }    
         |, { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD }     
        ]     
    )    
        [ WITH     
            { [ ALL_ERRORMSGS ]    
              [ , EXTENDED_LOGICAL_CHECKS ]     
              [ , NO_INFOMSGS ]    
              [ , TABLOCK ]     
              [ , ESTIMATEONLY ]     
              [ , { PHYSICAL_ONLY | DATA_PURITY } ]     
              [ , MAXDOP = number_of_processors ]    
            }    
        ]  

    》》3.有搜索到通过以下命令修复:是否可行,“repair_allow_data_loss”的数据丢失机制是怎样的?

    “repair_allow_data_loss”尝试修复报告的所有错误,恢复的数据库在物理层面的一致性,使其能够重新访问,但是这种修复是以丢失数据为前提的。另外运行具有 REPAIR_ALLOW_DATA_LOSS 选项的 DBCC CHECKDB 命令可能会影响用户数据库(发布数据库和订阅数据库)以及由复制使用的分发数据库。所以不到万不得已,不推荐你使用“repair_allow_data_loss”。 

    你目前最好且最简单的修复方式是还原最近的一次备份,实在没有备份,在使用“repair_allow_data_loss”,但是做好数据丢失的心理准备。关于修复损坏数据库的详细信息,你可以参考:DBCC CHECKDB (Transact-SQL)

    希望对你有用


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.



    2020年6月8日 1:40
  • 非常感谢您的回答,针对修复方式,还有几个疑问 

    我现在已经是一个万不得已的情况,在意外断电后,应用可以正常访问(可能时没有使用有问题数据的表,未发现问题),但是这个问题的暴露,是在一次日志备份失败后才发现的。三天过去了,已经有新的数据写入了,我已经不能使用历史的备份来恢复了。同时,今天早上的完整备份成功了,刚刚日志备份也成功了。
    1.
    具有 REPAIR_ALLOW_DATA_LOSS 选项的 DBCC CHECKDB 命令,会不会对生产时间的生产环境产生影响呢,只是一个单机的数据库,没有配置复制。
    2.现在完整和日志备份都已经成功了,但是windows应用日志中,这个报错以然存在,除了运行dbcc checktable之外,我还有什么动作可以做吗?还说说可以选择性忽略这个报错

    2020年6月8日 2:47
  • 你好,

    谢谢你的迅速反馈。

    针对您的问题,我建议您在DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS 执行修复之前,请创建属于此数据库的文件的物理副本。 这包括主数据文件 (.mdf)、任意辅助数据文件 (.ndf)、所有事务日志文件 (.ldf) 和构成数据库的其他容器,包括全文目录、文件流文件夹、内存优化数据等。在执行修复前,请考虑将数据库的状态更改为紧急模式,并尝试从关键表中提取尽可能多的信息并保存这些数据。或者您可以将该数据库导到非生产环境进行DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS,防止对您现在的生产环境产生影响。

    如果可以成功完整和日志备份,并且确保数据库的损坏对后续生产没有影响,您可以忽略这个报错。但是还是建议您将数据库修复好,防止不可预知的错误产生影响。


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    2020年6月8日 5:39
  • 感谢您的建议,我们结合实际生产情况,只能选择进行选择性的忽视,因为当前的服务器负载和应用的访问情况,不允许我进行长时间的dbcc checkdb命令(dbcc命令预计要进行20小时,同时在运行过程中,应用已经出现了访问缓慢,无法登录,服务器繁忙等报错)。在彻底忽视之前,还有最后一个小问题请教:
    据我了解dbcc checktable的命令必须要针对指定的表名,否则参数不完整无法执行。而我当前【页(3:1557398)】只有这个信息,没有具体的表名,也就是无法运行checktable的命令,只能运行checkdb,但是又在应用端遇到阻碍。
    所以在最终忽视这个报错前,还想确认到底是哪个表,哪些数据出现了问题,通过
    .页(3:1557398)可以判断出来吗? 
    2020年6月8日 8:40
  • 你好,

    为了诊断问题出现的地方,你可以用以下方法:

    1.用DBCC CHECKDB\DBCC CHECKTABLES

    2.在不运行DBCC CHECKDB的情况下查找表中错误的确切位置, 您将需要查找在查询搜索期间使用的表。

    3.您也可以使用“ SQL事件探查器( SQL Profiler)”在查询中查找确切的问题。

    你可以参考这篇文章:How to troubleshoot Msg 7105 in SQL Server

    除此之外,你也可以用DBCC PAGE查询表和索引数据:利用DBCC PAGE查看SQL Server中的表和索引数据

    SQL Server: How to find Table name from Page ID?

    SELECT * FROM [msdb].[dbo].[suspect_pages];  --查找有问题的数据库ID,文件ID和页码
    go
    
    DBCC TRACEON (3604);
    DBCC Page (6,3,1557398);   --根据你的报错信息,数据库ID是6,文件ID是3,页码是1557398
    DBCC TRACEOFF (3604);
    go
    
    SELECT OBJECT_NAME (ObjectId);  --查看有问题的元数据
    go



    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.


    2020年6月8日 9:05
  • 请问您的问题解决了吗?
    如果您觉得我们的回复解决了该问题,请帮忙‘标记为答案'以帮助其他社区成员迅速找到有用的答复。
    如果没有,请回复并告诉我们当前情况,以便提供进一步的帮助。

    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    2020年6月9日 1:01