GAM、SGAM 或 PFS 页上存在页错误处理

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:GAM、SGAM 或 PFS 页上存在页错误处理

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

有客户sql server数据库由于硬件故障,导致dbcc的时候报类似GAM、SGAM 或 PFS 页上存在页错误

kzj2025的 DBCC 结果。
Service Broker 消息 9675,状态 1: 已分析的消息类型: 14。
Service Broker 消息 9676,状态 1: 已分析的服务约定: 6。
Service Broker 消息 9667,状态 1: 已分析的服务: 3。
Service Broker 消息 9668,状态 1: 已分析的服务队列: 3。
Service Broker 消息 9669,状态 1: 已分析的会话端点: 0。
Service Broker 消息 9674,状态 1: 已分析的会话组: 0。
Service Broker 消息 9670,状态 1: 已分析的远程服务绑定: 0。
Service Broker 消息 9605,状态 1: 已分析的会话优先级: 0。
消息 8939,级别 16,状态 98,第 1 行
表错误: 对象 ID 0,索引 ID -1,分区 ID 0,分配单元 ID -2958221917649371136 
(类型为 Unknown),页 (12337:808857908)。测试(IS_OFF (BUF_IOERR, pBUF->bstat))失败。值为 12716041 和 -10。
消息 8998,级别 16,状态 2,第 1 行
GAM、SGAM 或 PFS 页上存在页错误,无法对数据库 ID 6 中从 (1:186024) 到 (1:194111) 
 的页继续进行分配完整性检查。原因请参阅其他错误消息。
CHECKDB 发现有 2 个分配错误和 0 个一致性错误与任何单个的对象都没有关联。
sys.sysrscols的 DBCC 结果。
对象 'sys.sysrscols' 的 171 页中有 16248 行。
sys.sysrowsets的 DBCC 结果。
……………………
对象 'gspz_pmaintainidx' 的 12 页中有 1658 行。
DiseasesMedicationsIndex_temp的 DBCC 结果。
对象 'DiseasesMedicationsIndex_temp' 的 0 页中有 0 行。
GSP_BackBill的 DBCC 结果。
对象 'GSP_BackBill' 的 0 页中有 0 行。
Gsp_L_KwGradeIndex的 DBCC 结果。
对象 'Gsp_L_KwGradeIndex' 的 0 页中有 0 行。
Web_T_Message的 DBCC 结果。
对象 'Web_T_Message' 的 0 页中有 0 行。
CHECKDB 在数据库 'kzj2025' 中发现 2 个分配错误和 0 个一致性错误。
DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。

完成时间: 2025-03-29T19:53:21.6977003+08:00

QQ20250329-225441


由于GAM、SGAM 或 PFS是和sql数据库文件的空间分配有关系,对于这种情况,一般无法直接修复,需要对库进行重构的方法进行修复,我们处理之后,dbcc检查一切正常
dbcc-ok

sql数据库备份失败—失败: 23(数据错误(循环冗余检查)

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:sql数据库备份失败—失败: 23(数据错误(循环冗余检查)

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

有客户sql server数据库备份失败,提示如下
bk-fail


从这个报错看,比较明显是由于底层(文件系统损坏或者扇区访问异常导致),进一步查看系统事件确认是由于扇区异常导致(设备\Device\HarddiskO\DR0有一个不正确的区块)
disk-error

对于这种情况,当访问到文件所在的损坏扇区位置,就会报io错误,终止访问,文件也无法直接拷贝.通过专业工具对文件进行拷贝恢复确认一些扇区损坏而且被跳过(这部分数据肯定丢失)
sq

由于文件本身跳过了损坏的扇区,需要确认损坏的部分影响哪些对象和哪些类型的损坏,通过DBCC检测出来异常信息如下

消息 8976,级别 16,状态 1,第 1 行
表错误: 对象 ID 1478296326,索引 ID 70,分区 ID 72057594244038656,分配单元 ID 72057594277527552 (类型为 In-row data)。在扫描过程中未发现页 (1:1577857),但该页的父级 (1:87825) 和上一页 (1:1576364) 都引用了它。请检查以前的错误消息。
消息 8978,级别 16,状态 1,第 1 行
表错误: 对象 ID 1478296326,索引 ID 70,分区 ID 72057594244038656,分配单元 ID 72057594277527552 (类型为 In-row data)。页 (1:1577859) 缺少上一页 (1:1577857) 对它的引用。可能是链链接有问题。
消息 8939,级别 16,状态 98,第 1 行
表错误: 对象 ID 1478296326,索引 ID 70,分区 ID 72057594244038656,分配单元 ID 72057594277527552 (类型为 In-row data),页 (1:1577857)。测试(IS_OFF (BUF_IOERR, pBUF->bstat))失败。值为 133129 和 -4。
消息 8928,级别 16,状态 1,第 1 行
对象 ID 1478296326,索引 ID 70,分区 ID 72057594244038656,分配单元 ID 72057594277527552 (类型为 In-row data): 无法处理页 (1:1577857)。有关详细信息,请参阅其他错误消息。


消息 8939,级别 16,状态 98,第 1 行
表错误: 对象 ID 2005582183,索引 ID 66,分区 ID 72057594242859008,分配单元 ID 72057594276347904 (类型为 In-row data),页 (1:385339)。测试(IS_OFF (BUF_IOERR, pBUF->bstat))失败。值为 133129 和 -4。
消息 8928,级别 16,状态 1,第 1 行
对象 ID 2005582183,索引 ID 66,分区 ID 72057594242859008,分配单元 ID 72057594276347904 (类型为 In-row data): 无法处理页 (1:385339)。有关详细信息,请参阅其他错误消息。
消息 8976,级别 16,状态 1,第 1 行
表错误: 对象 ID 2005582183,索引 ID 66,分区 ID 72057594242859008,分配单元 ID 72057594276347904 (类型为 In-row data)。在扫描过程中未发现页 (1:385339),但该页的父级 (1:127857) 和上一页 (1:385338) 都引用了它。请检查以前的错误消息。
消息 8978,级别 16,状态 1,第 1 行
表错误: 对象 ID 2005582183,索引 ID 66,分区 ID 72057594242859008,分配单元 ID 72057594276347904 (类型为 In-row data)。页 (1:1682744) 缺少上一页 (1:385339) 对它的引用。可能是链链接有问题。

然后通过DBCC进行修复,修复成功提示如下

修复: 已为数据库 'myhis' 中的对象 'dbo.h_xxxxx, idx_xxxxx_ckdmx_id' 成功地重新生成了 Nonclustered 索引。
修复: 页 (1:1577857) 已从对象 ID 1478296326,索引 ID 70,分区 ID 72057594244038656,分配单元 ID 72057594277527552 (类型为 In-row data)释放。
消息 8945,级别 16,状态 1,第 6 行
表错误: 将重新生成对象 ID 1478296326,索引 ID 70。
        该错误已修复。
消息 8928,级别 16,状态 1,第 6 行
对象 ID 1478296326,索引 ID 70,分区 ID 72057594244038656,分配单元 ID 72057594277527552 (类型为 In-row data): 无法处理页 (1:1577857)。有关详细信息,请参阅其他错误消息。
        该错误已修复。
消息 8939,级别 16,状态 98,第 6 行
表错误: 对象 ID 1478296326,索引 ID 70,分区 ID 72057594244038656,分配单元 ID 72057594277527552 (类型为 In-row data),页 (1:1577857)。测试(IS_OFF (BUF_IOERR, pBUF->bstat))失败。值为 2057 和 -4。
        该错误已修复。
消息 8976,级别 16,状态 1,第 6 行
表错误: 对象 ID 1478296326,索引 ID 70,分区 ID 72057594244038656,分配单元 ID 72057594277527552 (类型为 In-row data)。在扫描过程中未发现页 (1:1577857),但该页的父级 (1:87825) 和上一页 (1:1576364) 都引用了它。请检查以前的错误消息。
        该错误已修复。
消息 8978,级别 16,状态 1,第 6 行
表错误: 对象 ID 1478296326,索引 ID 70,分区 ID 72057594244038656,分配单元 ID 72057594277527552 (类型为 In-row data)。页 (1:1577859) 缺少上一页 (1:1577857) 对它的引用。可能是链链接有问题。
        该错误已修复。
对象 'h_zysfdmx' 的 365541 页中有 2705291 行。
CHECKDB 在表 'h_xxxxx' (对象 ID 1478296326)中发现 0 个分配错误和 4 个一致性错误。
CHECKDB 在表 'h_xxxxx' (对象 ID 1478296326)中修复了 0 个分配错误和 4 个一致性错误。

修复: 已为数据库 'myhis' 中的对象 'dbo.h_xxx, idx_xxx_ckdmx_id' 成功地重新生成了 Nonclustered 索引。
修复: 页 (1:385339) 已从对象 ID 2005582183,索引 ID 66,分区 ID 72057594242859008,分配单元 ID 72057594276347904 (类型为 In-row data)释放。
消息 8945,级别 16,状态 1,第 6 行
表错误: 将重新生成对象 ID 2005582183,索引 ID 66。
        该错误已修复。
消息 8928,级别 16,状态 1,第 6 行
对象 ID 2005582183,索引 ID 66,分区 ID 72057594242859008,分配单元 ID 72057594276347904 (类型为 In-row data): 无法处理页 (1:385339)。有关详细信息,请参阅其他错误消息。
        该错误已修复。
消息 8939,级别 16,状态 98,第 6 行
表错误: 对象 ID 2005582183,索引 ID 66,分区 ID 72057594242859008,分配单元 ID 72057594276347904 (类型为 In-row data),页 (1:385339)。测试(IS_OFF (BUF_IOERR, pBUF->bstat))失败。值为 2057 和 -4。
        该错误已修复。
消息 8976,级别 16,状态 1,第 6 行
表错误: 对象 ID 2005582183,索引 ID 66,分区 ID 72057594242859008,分配单元 ID 72057594276347904 (类型为 In-row data)。在扫描过程中未发现页 (1:385339),但该页的父级 (1:127857) 和上一页 (1:385338) 都引用了它。请检查以前的错误消息。
        该错误已修复。
消息 8978,级别 16,状态 1,第 6 行
表错误: 对象 ID 2005582183,索引 ID 66,分区 ID 72057594242859008,分配单元 ID 72057594276347904 (类型为 In-row data)。页 (1:1682744) 缺少上一页 (1:385339) 对它的引用。可能是链链接有问题。
        该错误已修复。
对象 'h_sfdmx' 的 1226 页中有 10928 行。
CHECKDB 在表 'h_xxx' (对象 ID 2005582183)中发现 0 个分配错误和 4 个一致性错误。
CHECKDB 在表 'h_xxx' (对象 ID 2005582183)中修复了 0 个分配错误和 4 个一致性错误。

QQ20250320-220759


再次使用DBCC检查数据库,一切正常,没有其他报错.然后在恢复过程中ldf文件也有大量扇区异常,对ldf文件进行截断处理

ALTER DATABASE MYHIS SET RECOVERY SIMPLE;
DBCC SHRINKFILE (MYHIS_log, 0);
ALTER DATABASE MYHIS SET RECOVERY FULL;

sql server数据库“正在恢复”故障处理

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:sql server数据库“正在恢复”故障处理

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

客户的sql server数据库在未知情况下,突然不可用,然后查看发现数据库处于“正在恢复”状态,无法使用
zzhf


查看日志发现“错误:10982,严重性:16,状态:1”
rz

,
查看数据库文件情况
QQ20250210-201158

通过分析确认mdf文件本身完整,没有异常,强制挂载mdf文件如下错误
20250210182925

通过一些技巧进行规避,数据库挂载成功,并且checkdb检查正常,没有任何错误,至此完成该故障恢复
checkdb

数据库附加失败 错误5172

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:数据库附加失败 错误5172

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

SQL server 数据库附加附失败 错误 5172
sql-attach-err


通过分析是由于ldf文件损坏(具体原因是客户被中勒索病毒,部分文件解密没有彻底成功)
ldf-error

通过人工特殊处理,附加数据库成功,数据库checkdb检测正常,数据查询正常
20221126194946
20221127125234

如果有sql 数据库问题无法自行解决,需要专业恢复技术支持,请联系我们:专业Sql Server数据库恢复服务
电话/微信:17813235971    Q Q:107644445QQ咨询惜分飞    E-Mail:dba@xifenfei.com

sql server 删除数据库恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:sql server 删除数据库恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

有客户通过sql server控制台,直接把一个生产库给删除了.删除之后客户没有做任何操作,联系到我们,通过工具反删除恢复,未找到正确文件(根据经验有时候就算恢复出来文件也大量坏块).只能采用底层技术进行恢复,使用sql扫描磁盘发现效果良好
20201121221315


恢复出来mdf文件,但是没有ldf文件,无法直接附加数据库,只能通过强制发放进行附加尝试
20201121222950

20201121222901

20201121222754

20201121222725

运气不错,强制附加成功,数据库可以查询,如果无法附加成功,或者查询表报错,可以通过mdf文件单独处理,最大限度恢复数据
20201121223109

如果你不小心删除了sql server的数据库,请第一时间保护现场,联系我们,可以最大限度恢复数据,减少损失,请参考:专业Sql Server数据库恢复服务,如果需要联系我们:
电话/微信:17813235971    Q Q:107644445QQ咨询惜分飞    E-Mail:dba@xifenfei.com

sql server 数据库由于操作错库删除表恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:sql server 数据库由于操作错库删除表恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

有客户找到我们,由于操作不当把原本应该在备库上执行的drop table语句放到生产库上来执行了,导致生产库的表全部被干掉
20200416220255


通过让客户提供相关的数据文件进行分析并进行恢复,由于客户删除掉表之后没有进行其他操作,因此恢复效果很好.
20200416215043

20200416220601

如果有sql server数据库被误操作(drop,truncate,delete 表等),应该第一时间避免写操作,比如:脱机拷贝数据文件,停掉所有数据库操作等防止由于进一步的写入导致覆盖,从而使得恢复效果不好.如果有恢复需求,可以联系我们.

sql server 数据库 mdf 0kb 恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:sql server 数据库 mdf 0kb 恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

以前恢复过oracle数据库dbf文件大小变为0kb的case(Oracle 数据文件大小为0kb或者文件丢失恢复),这次遇到一个客户由于主机重启导致sql server 数据库的mdf文件大小变为0kb,客户自己通过反删除软件无法正常恢复,我们通过磁盘底层block对其进行处理,实现大部分数据恢复(由于客户的一些操作导致部分数据覆盖)
该磁盘分区有多个mdf文件(多个sql server库)
20200303190055
通过底层block技术发现大量没有覆盖的该文件的block
20200303190141
20200303190332
通过block技术恢复出来mdf文件之后,然后恢复出来表数据情况
20200303190617


如果您遇到sql server 数据库由于某种原因导致mdf文件大小变为0kb,请第一时间保护现场,不要进行任何写操作,我们可以最大限度对其进行恢复,尽可能减少您的损失
Tel/微信:17813235971    Q Q:107644445 QQ咨询惜分飞    E-Mail:dba@xifenfei.com提供专业的恢复服务.