DBCC CHECKDB and repair

最新推荐文章于 2026-05-27 14:48:02 发布
原创 最新推荐文章于 2026-05-27 14:48:02 发布 · 2k 阅读 · 0 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
标签
#allocation #object #table #database #sql server
#sqlserver
本文通过两个实验演示了在遇到损坏的数据页和PFS页时使用DBCC CHECKDB命令的不同效果，揭示了为什么通常建议恢复已知良好的数据库备份而非直接修复。

Topic

When a database is corrupted, we will alwayssuggest restoring last known good database backup instead of running DBCCCHECKDB command to fix it. Can you explain why? Try to use a demo to show whyDBCC CHECKDB command is not always a first choice for a corrupted database.

 

Answer:

REPAIR_ALLOW_DATA_LOSS

·        The purpose of repair is not to save user data.The purpose of repair is to make the database structurally consistent as fast as possible(to limit downtime) and correctly (to avoid making things worse). 

·        This means that repairs have to be engineered tobe fast and reliable operations that will work in every circumstance. Thesimple way to do this is to delete what's broken and fix up everything thatlinked to (or was linked from) the thing being deleted - whether a record orpage.

·        This means that repairs have to be engineered tobe fast and reliable operations that will work in every circumstance. Thesimple way to do this is to delete what's broken and fix up everything thatlinked to (or was linked from) the thing being deleted - whether a record orpage.

·        Things to look for that mean repair won’t be ableto fix everything are:

    • CHECKDB stops early and complains about system table pre-checks failing (errors 7984 – 7988 inclusive)
    • CHECKDB reports any metadata corruption (8992, 8995 errors)
    • CHECKDB reports any errors on PFS page headers (8939, 8946 errors with a possible 8998 error as well)

Test1: Damage the data page

--create a test database

usemaster

createdatabase testcheckdb

usetestcheckdb

 

--create table t3

droptable t3

createtable t3

(

    c1 int primarykey,

    c2 nvarchar(50)

)

 

--insert a row (0, 'ABCDEFG')

select* from t3

insertinto t3 values(0,'ABCDEFG')

go

 

--insert 1000 rows

declare@count int

set@count = 1

WHILE@count <= 1000

   BEGIN

      insert into t3values(@count,'abc')

      set@count = @count+1

   END;

GO

 

--check data

select* from t3

--check page

dbcctraceon(3604)

DBCCind('testcheckdb', t3,-1)

--//154-IAMpage;155-index root page;153,156,157-data page

DBCCpage('testcheckdb', 1,154,3)--//

DBCCpage('testcheckdb', 1,155,3)--//

DBCCpage('testcheckdb', 1,153,3)--// m_slotCnt = 351


DBCCpage('testcheckdb', 1,156,3)--// m_slotCnt = 352

DBCCpage('testcheckdb', 1,157,3)--// m_slotCnt = 298

 

--set db offline

usemaster

alterdatabase testcheckdbsetoffline

 


--modify the data page

 

 

alterdatabase testcheckdbsetonline

--check data again

usetestcheckdb

select* from t3

•       SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0x54781bb2;actual: 0x54781c32). Itoccurredduring a read of page (1:153) in database ID 12 at offset0x00000000132000 in file 'C:\Program Files\Microsoft SQLServer\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\testcheckdb.mdf'.  Additional messages in the SQL Server errorlog or system event log may provide more detail. This is a severe errorcondition that threatens database integrity and must be corrected immediately.Complete a full database consistencycheck (DBCC CHECKDB). This error can be caused by many factors; formore information, see SQL Server Books Online.

 

USEtestcheckdb

DBCCCHECKDB(12)

GO

 

usemaster

ALTERDATABASE testcheckdbSETSINGLE_USER;

GO

 


DBCCCHECKDB(12, REPAIR_ALLOW_DATA_LOSS)

WITHALL_ERRORMSGS,NO_INFOMSGS

GO


Repair: TheClustered index successfully rebuilt for the object "dbo.t3" indatabase "testcheckdb".

Repair: Thepage (1:153) has been deallocated from object ID 2105058535, index ID 1,partition ID 72057594038779904, alloc unit ID 72057594039697408 (type In-rowdata).

Msg 8945,Level 16, State 1, Line 1

Table error:Object ID 2105058535, index ID 1 will be rebuilt.

        The error has been repaired.

Msg 8928,Level 16, State 1, Line 1

Object ID2105058535, index ID 1, partition ID 72057594038779904, alloc unit ID72057594039697408 (type In-row data): Page (1:153) could not be processed.  See other errors for details.

        The error has been repaired.

Msg 8939,Level 16, State 98, Line 1

Table error:Object ID 2105058535, index ID 1, partition ID 72057594038779904, alloc unit ID72057594039697408 (type In-row data), page (1:153). Test (IS_OFF (BUF_IOERR,pBUF->bstat)) failed. Values are 12584969 and -4.

        The error has been repaired.

Msg 8980,Level 16, State 1, Line 1

Table error:Object ID 2105058535, index ID 1, partition ID 72057594038779904, alloc unit ID72057594039697408 (type In-row data). Index node page (1:155), slot 0 refers tochild page (1:153) and previous child (0:0), but they were not encountered.

        The error has been repaired.

Msg 8978,Level 16, State 1, Line 1

Table error:Object ID 2105058535, index ID 1, partition ID 72057594038779904, alloc unit ID72057594039697408 (type In-row data). Page (1:156) is missing a reference fromprevious page (1:153). Possible chain linkage problem.

        The error has been repaired.

CHECKDBfound 0 allocation errors and 4 consistency errors in table 't3' (object ID2105058535).

CHECKDBfixed 0 allocation errors and 4 consistency errors in table 't3' (object ID2105058535).

CHECKDBfound 0 allocation errors and 4 consistency errors in database 'testcheckdb'.

CHECKDBfixed 0 allocation errors and 4 consistency errors in database 'testcheckdb'.



 

usetestcheckdb

--check data again

select* from t3


--check page again

dbcctraceon(3604)

DBCCind('testcheckdb', t3,-1)

--//former: 154-IAMpage;155-index root page;153,156,157-data page

--//now:   159-IAMpage;169-index rootpage;158,168-data page

DBCCpage('testcheckdb', 1,159,3)--//

DBCCpage('testcheckdb', 1,169,3)--//

DBCCpage('testcheckdb', 1,158,3)--// m_slotCnt = 352

DBCC page('testcheckdb', 1,168,3)--// m_slotCnt = 298 

 


 

Test2: Damage the PFS page

--//check the PFS page

DBCCpage('testcheckdb', 1,1,2)-


--thenI modify it physically.


--then online the db , selectand insert.

--check the data, valid.

usetestcheckdb

select* from t3

--insert a row, valid

insertinto t3 values(1001,'ABCD')

--insert another 1000 rows, just 52 rows inserted ok. The following failed

declare@count int

set@count = 1002

WHILE@count <= 2000

   BEGIN

      insert into t3values(@count,'abc')

      set@count = @count+1

   END;

GO


 

Thestatement has been terminated.

Msg824, Level 24, State 2, Line 5

SQLServer detected a logical consistency-based I/O error: incorrect checksum(expected: 0x20c60630; actual: 0x80660ace). It occurred during a read of page(1:1) in database ID 12 at offset 0x00000000002000 in file 'C:\ProgramFiles\Microsoft SQLServer\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\testcheckdb.mdf'.  Additional messages in the SQL Server errorlog or system event log may provide more detail. This is a severe errorcondition that threatens database integrity and must be corrected immediately.Complete a full database consistency check (DBCC CHECKDB). This error can becaused by many factors; for more information, see SQL Server Books Online.

 

--then try to check page

dbcctraceon(3604)

DBCCind('testcheckdb', t3,-1)

--//former: 154-IAMpage;155-index root page;153,156,157-data page

--//now:   159-IAMpage;169-index rootpage;158,168-data page

dbcctraceon(3604)

DBCCpage('testcheckdb', 1,159,3)--//

DBCCpage('testcheckdb', 1,169,3)--//

DBCCpage('testcheckdb', 1,158,3)--// former m_slotCnt = 352, now m_slotCnt = 352

DBCC page('testcheckdb', 1,168,3)--// former m_slotCnt =298, now m_slotCnt = 351

--checkdb

DBCCCHECKDB(12)

WITHALL_ERRORMSGS,NO_INFOMSGS

GO

 

Msg 8921, Level 16, State 1, Line 1

Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.

Msg 8998, Level 16, State 2, Line 1

Page errors on the GAM, SGAM, or PFS pages prevent allocation integrity checks in database ID 12 pages from (1:0) to (1:8087). See other errors for cause.

CHECKDB found 1 allocation errors and 0 consistency errors not associated with any single object.

Msg 2575, Level 16, State 1, Line 1

The Index Allocation Map (IAM) page (1:86) is pointed to by the next pointer of IAM page (0:0) in object ID 3, index ID 1, partition ID 196608, alloc unit ID 196608 (type In-row data), but it was not detected in the scan.

CHECKDB found 1 allocation errors and 0 consistency errors in table 'sys.sysrscols' (object ID 3).

Msg 2575, Level 16, State 1, Line 1

The Index Allocation Map (IAM) page (1:131) is pointed to by the next pointer of IAM page (0:0) in object ID 5, index ID 1, partition ID 327680, alloc unit ID 327680 (type In-row data), but it was not detected in the scan.

CHECKDB found 1 allocation errors and 0 consistency errors in table 'sys.sysrowsets' (object ID 5).

Msg 2575, Level 16, State 1, Line 1

The Index Allocation Map (IAM) page (1:17) is pointed to by the next pointer of IAM page (0:0) in object ID 7, index ID 1, partition ID 458752, alloc unit ID 458752 (type In-row data), but it was not detected in the scan.

Msg 2575, Level 16, State 1, Line 1

The Index Allocation Map (IAM) page (1:54) is pointed to by the next pointer of IAM page (0:0) in object ID 7, index ID 2, partition ID 562949953880064, alloc unit ID 562949953880064 (type In-row data), but it was not detected in the scan.

CHECKDB found 2 allocation errors and 0 consistency errors in table 'sys.sysallocunits' (object ID 7).

Msg 2575, Level 16, State 1, Line 1

The Index Allocation Map (IAM) page (1:12) is pointed to by the next pointer of IAM page (0:0) in object ID 8, index ID 0, partition ID 524288, alloc unit ID 524288 (type In-row data), but it was not detected in the scan.

CHECKDB found 1 allocation errors and 0 consistency errors in table 'sys.sysfiles1' (object ID 8).

Msg 2575, Level 16, State 1, Line 1

The Index Allocation Map (IAM) page (1:26) is pointed to by the next pointer of IAM page (0:0) in object ID 19, index ID 1, partition ID 281474977955840, alloc unit ID 281474977955840 (type In-row data), but it was not detected in the scan.

CHECKDB found 1 allocation errors and 0 consistency errors in table 'sys.sysfgfrag' (object ID 19).

Msg 2575, Level 16, State 1, Line 1

The Index Allocation Map (IAM) page (1:28) is pointed to by the next pointer of IAM page (0:0) in object ID 23, index ID 1, partition ID 281474978217984, alloc unit ID 281474978217984 (type In-row data), but it was not detected in the scan.

CHECKDB found 1 allocation errors and 0 consistency errors in table 'sys.sysphfg' (object ID 23).

Msg 2575, Level 16, State 1, Line 1

The Index Allocation Map (IAM) page (1:30) is pointed to by the next pointer of IAM page (0:0) in object ID 24, index ID 1, partition ID 281474978283520, alloc unit ID 281474978283520 (type In-row data), but it was not detected in the scan.

CHECKDB found 1 allocation errors and 0 consistency errors in table 'sys.sysprufiles' (object ID 24).

Msg 2575, Level 16, State 1, Line 1

The Index Allocation Map (IAM) page (1:92) is pointed to by the next pointer of IAM page (0:0) in object ID 27, index ID 1, partition ID 281474978480128, alloc unit ID 281474978480128 (type In-row data), but it was not detected in the scan.

…………

Msg 2575, Level 16, State 1, Line 1

The Index Allocation Map (IAM) page (1:74) is pointed to by the next pointer of IAM page (0:0) in object ID 93, index ID 2, partition ID 562949959516160, alloc unit ID 562949959516160 (type In-row data), but it was not detected in the scan.

CHECKDB found 2 allocation errors and 0 consistency errors in table 'sys.sysxmlplacement' (object ID 93).

Msg 2575, Level 16, State 1, Line 1

The Index Allocation Map (IAM) page (1:137) is pointed to by the next pointer of IAM page (0:0) in object ID 97, index ID 1, partition ID 281474983067648, alloc unit ID 281474983067648 (type In-row data), but it was not detected in the scan.

Msg 2575, Level 16, State 1, Line 1

The Index Allocation Map (IAM) page (1:139) is pointed to by the next pointer of IAM page (0:0) in object ID 97, index ID 2, partition ID 562949959778304, alloc unit ID 562949959778304 (type In-row data), but it was not detected in the scan.

CHECKDB found 2 allocation errors and 0 consistency errors in table 'sys.sysbinsubobjs' (object ID 97).

Msg 8939, Level 16, State 98, Line 1

Table error: Object ID 99, index ID 0, partition ID 0, alloc unit ID 6488064 (type System allocation data), page (1:1). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12584969 and -4.

Msg 8939, Level 16, State 98, Line 1

Table error: Object ID 99, index ID 0, partition ID 0, alloc unit ID 6488064 (type System allocation data), page (1:1). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12584969 and -4.

Msg 8939, Level 16, State 98, Line 1

Table error: Object ID 99, index ID 0, partition ID 0, alloc unit ID 6488064 (type System allocation data), page (1:1). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12584969 and -4.

Msg 8939, Level 16, State 98, Line 1

Table error: Object ID 99, index ID 0, partition ID 0, alloc unit ID 6488064 (type System allocation data), page (1:1). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12584969 and -4.

Msg 8939, Level 16, State 98, Line 1

Table error: Object ID 99, index ID 0, partition ID 0, alloc unit ID 6488064 (type System allocation data), page (1:1). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12584969 and -4.

Msg 8939, Level 16, State 98, Line 1

Table error: Object ID 99, index ID 0, partition ID 0, alloc unit ID 6488064 (type System allocation data), page (1:1). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12584969 and -4.

CHECKDB found 5 allocation errors and 1 consistency errors in table '(Object ID 99)' (object ID 99).

Msg 2575, Level 16, State 1, Line 1

The Index Allocation Map (IAM) page (1:159) is pointed to by the next pointer of IAM page (0:0) in object ID 2105058535, index ID 1, partition ID 72057594038845440, alloc unit ID 72057594039762944 (type In-row data), but it was not detected in the scan.

CHECKDB found 1 allocation errors and 0 consistency errors in table 't3' (object ID 2105058535).

CHECKDB found 56 allocation errors and 1 consistency errors in database 'testcheckdb'.

 
 

 

 

 


--try to repair, fail

DBCCCHECKDB(12, REPAIR_ALLOW_DATA_LOSS)

WITHALL_ERRORMSGS,NO_INFOMSGS

GO


"CHECKDB uses the PFS pages to determine which pages are allocated - and so which pages to read to drive the various consistency checks.The only repair for a PFS page is to reconstruct it - they can't simply be deleted as they're a fixed part of the fabric of the database.PFS pages cannot be rebuilt because there is no infallible way to determine which pages are allocated or not.There are various algorithms I've experimented with to rebuild them, with optimistic or pessimistic setting of page allocation statuses and then re-running the various consistency checks to try to sort out the incorrect choices, but they allrequire very long run-times. Given the frequency with which these corruptions are seen, and the engineering effort required to come up with an (imperfect) solution, I made the choice to leave this as unrepairable, and I don’t think that will change in future."  ——Paul.S. Randal

 
DBCC CHECKDB用法 手工修复数据库
MZ199290的博客
06-20 6341
手工修复数据库 1、快速修复 DBCCCHECKDB('数据库名',REPAIR_FAST) 2、重建索引并修复 DBCCCHECKDB('数据库名',REPAIR_REBUILD) 3、如果必要允许丢失数据修复 DBCCCHECKDB('数据库名'',REPAIR_ALLOW_DATA_LOSS) 如果出现错误：未处理修复语句。数据库需处于单用户模式下。 可以先...
DBCC CHECKDB用法详解
zunguitiancheng的专栏
05-15 8009
首先，在SQL Enterprise中新建一数据库（如数据库名为test）,建好数据库后，停止SQL Server Service Manager，并将客户数据库的MDF文件更名为test _data.mdf(即新建数据库的主文件名)，然后用更名后的文件覆盖新建数据库同名文件，接着，启动SQL Server Service Manager。SQL SERVER提供了数据库检测的命令，可用DBCC CHECKDB对数据库中各个对象的分配及结构的正确性进行检测，并可通过一参数控制，将所有的错误信息显示出来。
SQL Server数据修复常用命令DBCC
jinxbin的专栏
12-19 2476
 　　MS Sql Server 提供了很多数据库修复的命令，当数据库质疑或是有的无法完成读取时可以尝试这些修复命令。 　　1. DBCC CHECKDB 　　重启服务器后，在没有进行任何操作的情况下，在SQL查询分析器中执行以下SQL进行数据库的修复，修复数据库存在的一致性错误与分配错误。 use master declare @databasename varchar(255) s
SQL Server中的事务日志管理的阶梯，6级：管理大容量日志恢复模型中的日志
weixin_30360497的博客
12-12 389
由Gail Shaw，托尼·戴维斯，2012/11/07该系列本文是SQL Server中“Stairway系列：事务日志管理的阶梯”的一部分当事情进展顺利的时候，没有必要特别意识到事务日志的作用或工作原理。你只需要确信每个数据库都有正确的备份机制。当事情出错时，对事务日志的理解对于采取纠正措施是非常重要的，特别是在需要时间点恢复数据库的情况下，迫切需要！托尼·戴维斯（Tony Davi...
[SQL SERVER] 基礎 DBCC CHECKDB 在做什麼、要花多久時間、大型資料庫執行CHECKDB方法
RyanSi的博客
07-05 4217
DBCC CHECKDB檢查指定資料庫中所有物件的完整性 檢查相關系統表 執行DBCC CHECKALLOC  (檢查資料庫所有頁面分配) 執行DBCC CHECKTABLE  ( 執行DBCC CHECKCATALOG 驗證索引檢視內容 驗證Service Broker資料 執行CHECKDB要花多久時間，跟下面因素有關 資料庫本身大小 磁碟IO能力  (c
sqlserver 关于DBCC CHECKDB的总结
cjh81378066的博客
07-01 1954
官方文档 https://docs.microsoft.com/zh-cn/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sq...
SQLSERVER 数据库或表修复(DBCC CHECKDB)
m0_50687721的博客
09-14 6352
数据库或表修复（DBCC CHECKDB）
SQL SERVER中dbcc checkdb 命令
whaxrl的专栏
10-12 2652
 语法 dbcc CHECKDB ( { 'database_name' | database_id | 0 } [ , NOINDEX | { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ] ) [ WITH {
除了REPAIR_ALLOW_DATA_LOSS，我们还能做什么？深入解读SQL Server DBCC CHECKDB的各种修复选项与适用场景
最新发布
weixin_30621711的博客
05-27 555
本文深入解析SQL Server DBCC CHECKDB的多种修复选项，包括REPAIR_FAST、REPAIR_REBUILD和REPAIR_ALLOW_DATA_LOSS，帮助DBA在面对数据库错误时做出精准决策。通过详细的使用场景和风险分析，提供从轻量级修复到激进手段的全面指南，确保数据安全与业务连续性。
DBCC--CHECKDB
weixin_30633949的博客
01-14 602
DBCC CHECKDB: 1.检查数据库是否有损坏 2.尽可能修复数据库损坏，是数据能重新被访问 DBCC CHECKDB执行流程 1.检查关键系统表 2.对数据库运行DBCC CHECKALLOC 3.对数据库中每个表或试图运行DBCC CHECKTABLE 4.对数据库运行DBCC CHECKCATLOG 5.验证数据库中每个索引试图的内容 6.验证数据库中Servi...
SQL Server 的DBCC命令
RulesChen的博客
08-02 7737
摘要： DBCC（Database Console Commands）是SQL Server中的一组诊断和维护命令，用于数据库管理、性能监控和修复。常见命令包括： DBCC CHECKDB检查数据库完整性 DBCC SHRINKDATABASE收缩数据库文件 DBCC SQLPERF监控性能统计 DBCC FREEPROCCACHE清除执行计划缓存 使用时需注意权限要求（如sysadmin角色）和性能影响，建议先在测试环境验证。DBCC命令是强大的管理工具，但需谨慎操作以避免数据风险。
dbcc mysql_DBCC CHECKDB 数据库或表修复
weixin_42475535的博客
01-19 718
1. DBCC CHECKDB 重启服务器后，在没有进行任何操作的情况下，在SQL查询分析器中执行以下SQL进行数据库的修复，修复数据库存在的一致性错误与分配错误。 use master declare @databasename varchar(255) set @databasename='需要修复的数据库实体的名称' exe1. DBCC CHECKDB重启服务器后，在没有进行任何操作的情况...
SQL Server数据库修复完全指南：DBCC CHECKDB实战
德仔
12-02 1843
摘要：本文介绍了SQL Server数据库物理损坏的检测与修复方法。重点讲解了DBCC CHECKDB命令的使用，包括检查数据库完整性、单用户模式修复流程、单表修复方法及常用DBCC命令。文章详细说明了修复选项的区别（REPAIR_REBUILD与REPAIR_ALLOW_DATA_LOSS），并提供了性能优化建议、日志文件处理方法以及预防措施。最后给出了完整的修复脚本模板，强调备份重于修复，建议定期检查数据库健康状况。全文约150字。
sqlserver实验心得体会_sqlserver 关于DBCC CHECKDB的总结
weixin_33748493的博客
12-24 534
官方文档https://docs.microsoft.com/zh-cn/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-2017通过执行下列操作检查指定数据库中所有对象的逻辑和物理完整性：对数据库运行 DBCC CHECKALLOC。对数据库中的每个表和视图运行 DBCC CHECKTAB...
DBCC CHECKDB 手工修复数据库
chelen_jak的专栏
06-29 790
原文出处：https://blog.csdn.net/weixin_42384291/article/details/81149294?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.n
【SQL Server】DBCC CHECKDB只是一个数据库维护命令吗？
Commas的博客
07-28 2898
DBCC CHECKDB 不仅仅是一个数据库维护命令，更是一个数据库修复命令，更多详情，请看文章...
SQL SERVER数据库修复之REPAIR_ALLOW_DATA_LOSS级别简介和实例
zyypjc的博客
12-05 3756
如果我们没有数据库备份，无法使用页面还原，那么我们就需要用repair_allow_data_loss来修复（会有数据损失，而且不一定所有的都是可以恢复的）一般来说，最小的修复级别是repair_allow_data_loss。
数据库修复系列Part3:repair_allow_data_loss
Kevin's Blog SQL讨论群21426959 Dynamics AX 438084988
08-05 5333
运行DBCC CHECKDB withNO_INFOMSGS发现下面的错误：   Table error: ObjectID 7, index ID 2, partition ID 562949953880064, alloc unit ID 562949953880064(type In-row data), page (1:54). Test ((m_type >= DATA_PAGE &
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值