34,590
社区成员
发帖
与我相关
我的任务
分享未能读取并闩锁页
服务器: 消息 8966，级别 16，状态 2，行 4
未能读取并闩锁页 (1:3700752)（用闩锁类型 UP）。䏴䩐 失败。
服务器: 消息 8966，级别 16，状态 1，行 4
未能读取并闩锁页 (1:3700753)（用闩锁类型 UP）。䏴䩐 失败。
服务器: 消息 8966，级别 16，状态 1，行 4
未能读取并闩锁页 (1:3700754)（用闩锁类型 UP）。䏴䩐 失败。
服务器: 消息 8966，级别 16，状态 1，行 4
未能读取并闩锁页 (1:3700755)（用闩锁类型 UP）。䏴䩐 失败。
服务器: 消息 8966，级别 16，状态 1，行 4
未能读取并闩锁页 (1:3700756)（用闩锁类型 UP）。䏴䩐 失败。
服务器: 消息 8966，级别 16，状态 1，行 4
未能读取并闩锁页 (1:3700757)（用闩锁类型 UP）。䏴䩐 失败。
服务器: 消息 8966，级别 16，状态 1，行 4
未能读取并闩锁页 (1:3700758)（用闩锁类型 UP）。䏴䩐 失败。
服务器: 消息 8966，级别 16，状态 1，行 4
未能读取并闩锁页 (1:3700759)（用闩锁类型 UP）。䏴䩐 失败。
'issposv5' 的 DBCC 结果。
CHECKDB 发现了 0 个分配错误和 8 个一致性错误，这些错误并不与任何单个的对象相关联。
能不能提示手工修复
未能读取并闩锁页 (1:3700752)（用闩锁类型 UP）。䏴䩐 失败。
服务器: 消息 8966，级别 16，状态 1，行 4
未能读取并闩锁页 (1:3700753)（用闩锁类型 UP）。䏴䩐 失败。
服务器: 消息 8966，级别 16，状态 1，行 4
未能读取并闩锁页 (1:3700754)（用闩锁类型 UP）。䏴䩐 失败。
服务器: 消息 8966，级别 16，状态 1，行 4
未能读取并闩锁页 (1:3700755)（用闩锁类型 UP）。䏴䩐 失败。
服务器: 消息 8966，级别 16，状态 1，行 4
未能读取并闩锁页 (1:3700756)（用闩锁类型 UP）。䏴䩐 失败。
服务器: 消息 8966，级别 16，状态 1，行 4
未能读取并闩锁页 (1:3700757)（用闩锁类型 UP）。䏴䩐 失败。
服务器: 消息 8966，级别 16，状态 1，行 4
未能读取并闩锁页 (1:3700758)（用闩锁类型 UP）。䏴䩐 失败。
服务器: 消息 8966，级别 16，状态 1，行 4
未能读取并闩锁页 (1:3700759)（用闩锁类型 UP）。䏴䩐 失败。
'issposv5' 的 DBCC 结果。
CHECKDB 发现了 0 个分配错误和 8 个一致性错误，这些错误并不与任何单个的对象相关联。
能不能提示手工修复
...全文
请发表友善的回复…
发表回复
bwu851 2008-07-13
- 打赏
- 举报
[Quote=引用 5 楼 fancydong 的回复:]
手工修复MDF文件,可以么?
[/Quote]
没听说过....
手工修复MDF文件,可以么?
[/Quote]
没听说过....
zhiguo2008 2008-07-12
- 打赏
- 举报
[Quote=引用 1 楼 hery2002 的回复:]
建议尝试把数据导出来,
然后重新建库,
参考:
-----------------
未能读取并闩锁页
http://topic.csdn.net/t/20061025/09/5106956.html
只有MDF恢复数据库，出现“未能读取并闩锁页 (5:681)（用闩锁类型 SH）”是什么错？
http://topic.csdn.net/t/20060801/10/4918525.html
SQL数据库损坏及恢复分析
http://blog.eccn.com/u/129864/archives/2007/3384.htm
[/Quote]
强烈支持
建议尝试把数据导出来,
然后重新建库,
参考:
-----------------
未能读取并闩锁页
http://topic.csdn.net/t/20061025/09/5106956.html
只有MDF恢复数据库，出现“未能读取并闩锁页 (5:681)（用闩锁类型 SH）”是什么错？
http://topic.csdn.net/t/20060801/10/4918525.html
SQL数据库损坏及恢复分析
http://blog.eccn.com/u/129864/archives/2007/3384.htm
[/Quote]
强烈支持
hery2002 2008-07-12
- 打赏
- 举报
那就看看官方解释:也是这么说的.
CHECKDB (Part 2): What does CHECKDB really do? (1 of 4)
http://blogs.msdn.com/sqlserverstorageengine/archive/2006/06/19/636410.aspx
The primitive checks are designed to check that internal queries on the metadata tables won't throw errors. Each of the critical system tables has a clustered index. The primitive checks just check the leaf-level data pages of the clustered indexes. For every one of these pages, the following is done:
Read and latch the page (a latch is a lightweight internal version of a lock). This makes sure that there aren't any IO problems with the page such as a torn-page or bad page checksum and ensures that we can put the page in the buffer pool correctly. This is the most common cause of failure of the primitive system table checks and results in error 8966, which in SQL Server 2000 could look something like:
Audit the page. This is a series of checks of the page structures which I'll cover in a seperate post. If these pass, the page looks like a SQL Server page of type its supposed to be.
Check the basic page linkage. Pages in each level of a clustered index are linked together in a doubly-linked list to allow range scans to work. At this stage we only check the left-to-right linkage to ensure the linked-to page actually exists.
Check the page linkage for loops. This is simple to do - have two pointers into the page linked-list with one advancing at every step and one advancing at every second step. If they ever point to the same thing before the faster-advancing pointer reaches the right-hand side of the leaf level then there's a loop. Its important that there are no linkage loops otherwise a range scan may turn into an infinite loop. I've never seen this occur in the field.
Any error found at this stage cannot be repaired so you must restore from a backup. This is because the repair would have to deallocate the page, effectively deleting metadata for a whole lot of tables and indexes. As people's databases get larger and more complex (thousands of tables and indexes), the percentage of pages that comprise these critical system tables rises and so the chance of a hardware problem corrupting one of these pages also rises - I see several of these a month on the forums. Without a backup, the only alternative is to try to export as much data as you can - not good.
CHECKDB (Part 2): What does CHECKDB really do? (1 of 4)
http://blogs.msdn.com/sqlserverstorageengine/archive/2006/06/19/636410.aspx
The primitive checks are designed to check that internal queries on the metadata tables won't throw errors. Each of the critical system tables has a clustered index. The primitive checks just check the leaf-level data pages of the clustered indexes. For every one of these pages, the following is done:
Read and latch the page (a latch is a lightweight internal version of a lock). This makes sure that there aren't any IO problems with the page such as a torn-page or bad page checksum and ensures that we can put the page in the buffer pool correctly. This is the most common cause of failure of the primitive system table checks and results in error 8966, which in SQL Server 2000 could look something like:
Server: Msg 8966, Level 16, State 1, Line 1
Could not read and latch page (1:33245) with latch type SH. sysobjects failed.Audit the page. This is a series of checks of the page structures which I'll cover in a seperate post. If these pass, the page looks like a SQL Server page of type its supposed to be.
Check the basic page linkage. Pages in each level of a clustered index are linked together in a doubly-linked list to allow range scans to work. At this stage we only check the left-to-right linkage to ensure the linked-to page actually exists.
Check the page linkage for loops. This is simple to do - have two pointers into the page linked-list with one advancing at every step and one advancing at every second step. If they ever point to the same thing before the faster-advancing pointer reaches the right-hand side of the leaf level then there's a loop. Its important that there are no linkage loops otherwise a range scan may turn into an infinite loop. I've never seen this occur in the field.
Any error found at this stage cannot be repaired so you must restore from a backup. This is because the repair would have to deallocate the page, effectively deleting metadata for a whole lot of tables and indexes. As people's databases get larger and more complex (thousands of tables and indexes), the percentage of pages that comprise these critical system tables rises and so the chance of a hardware problem corrupting one of these pages also rises - I see several of these a month on the forums. Without a backup, the only alternative is to try to export as much data as you can - not good.
fancydong 2008-07-12
- 打赏
- 举报
手工修复MDF文件,可以么?
hery2002 2008-07-12
- 打赏
- 举报
[Quote=引用 2 楼 fancydong 的回复:]
数据库太大了....30G
[/Quote]
o o
但是貌似没有更好的方式....
数据库太大了....30G
[/Quote]
o o
但是貌似没有更好的方式....
hery2002 2008-07-12
- 打赏
- 举报
在导出数据后,
可以尝试使用
修复一下,
如果不行的话,
那就重建数据库.
可以尝试使用
DBCC checkdb('数据库名',REPAIR_ALLOW_DATA_LOSS) 修复一下,
如果不行的话,
那就重建数据库.
fancydong 2008-07-12
- 打赏
- 举报
数据库太大了....30G
hery2002 2008-07-12
- 打赏
- 举报
建议尝试把数据导出来,
然后重新建库,
参考:
-----------------
未能读取并闩锁页
http://topic.csdn.net/t/20061025/09/5106956.html
只有MDF恢复数据库，出现“未能读取并闩锁页 (5:681)（用闩锁类型 SH）”是什么错？
http://topic.csdn.net/t/20060801/10/4918525.html
SQL数据库损坏及恢复分析
http://blog.eccn.com/u/129864/archives/2007/3384.htm
然后重新建库,
参考:
-----------------
未能读取并闩锁页
http://topic.csdn.net/t/20061025/09/5106956.html
只有MDF恢复数据库，出现“未能读取并闩锁页 (5:681)（用闩锁类型 SH）”是什么错？
http://topic.csdn.net/t/20060801/10/4918525.html
SQL数据库损坏及恢复分析
http://blog.eccn.com/u/129864/archives/2007/3384.htm
fancydong 2008-07-12
- 打赏
- 举报
有相关MDF的数据结构的文档么?
utpcb 2008-07-12
- 打赏
- 举报
[Quote=引用 5 楼 fancydong 的回复:]
手工修复MDF文件,可以么?
[/Quote]
手工修复MDF文件,可以么?
[/Quote]
dlcyj 2008-07-12
- 打赏
- 举报
可以手工修复MDF，但前提是你懂MDF的数据结构吗？
