delay block cleanout的一点基本测试!

最新推荐文章于 2024-10-28 10:57:08 发布
最新推荐文章于 2024-10-28 10:57:08 发布
阅读量163 收藏
点赞数
文章标签： 数据库

这是一个delay block cleanout的最基本的测试，slot被覆盖的情况再讨论。

[@more@]

session 1:
SQL> insert into tt select * from tt;

已创建180096行。
SQL> select xidusn from v$transaction;

XIDUSN
----------
37

SQL> select usn,name from v$rollname where usn=37;

USN NAME
---------- ------------------------------
37 _SYSSMU37$
session 2
--analyze table是ddl命令，在session 1中执行此命令会commit事务
SQL> analyze table tt compute statistics;

表已分析。
--验证一下事务还在
SQL> select xidusn from v$transaction;

XIDUSN
----------
37
SQL> select blocks,empty_blocks from dba_tables where table_name='TT';

BLOCKS EMPTY_BLOCKS
---------- ------------
4540 68
SQL> select extent_id,file_id,block_id,blocks from dba_extents where segment_nam
e='TT';

EXTENT_ID FILE_ID BLOCK_ID BLOCKS
---------- ---------- ---------- ----------
0 4 9 8
1 4 17 8
2 4 25 8
3 4 33 8
4 4 41 8
5 4 49 8
6 4 57 8
7 4 65 8
8 4 73 8
9 4 81 8
10 4 89 8

EXTENT_ID FILE_ID BLOCK_ID BLOCKS
---------- ---------- ---------- ----------
11 4 97 8
12 4 105 8
13 4 113 8
14 4 121 8
15 4 129 8
16 4 137 128
17 4 265 128
18 4 393 128
19 4 521 128
20 4 649 128
21 4 777 128

EXTENT_ID FILE_ID BLOCK_ID BLOCKS
---------- ---------- ---------- ----------
22 4 905 128
23 4 1033 128
24 4 1161 128
25 4 1289 128
26 4 1417 128
27 4 1545 128
28 4 1673 128
29 4 1801 128
30 4 1929 128
31 4 2057 128
32 4 2185 128

EXTENT_ID FILE_ID BLOCK_ID BLOCKS
---------- ---------- ---------- ----------
33 4 2313 128
34 4 2441 128
35 4 2569 128
36 4 2697 128
37 4 2825 128
38 4 2953 128
39 4 3081 128
40 4 3209 128
41 4 3337 128
42 4 3465 128
43 4 3593 128

EXTENT_ID FILE_ID BLOCK_ID BLOCKS
---------- ---------- ---------- ----------
44 4 3721 128
45 4 3849 128
46 4 3977 128
47 4 4105 128
48 4 4233 128
49 4 4361 128
50 4 4489 128

已选择51行。
--后面的68个block是empty的，我们从4489开始去4495验证delay block cleanout
此时事务没有提交，所以4495block的itl 0x01中没有提交信息（从flag，lck，Scn/Fsn都可以看出来）
SQL> alter system dump datafile 4 block 4495;

系统已更改。

SQL>
--=============================
Start dump data blocks tsn: 4 file#: 4 minblk 4495 maxblk 4495
buffer tsn: 4 rdba: 0x0100118f (4/4495)
scn: 0x0000.001c7d1f seq: 0x01 flg: 0x04 tail: 0x7d1f0601
frmt: 0x02 chkval: 0x9785 type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x08732200 to 0x08734200
.............省去无关信息
Block header dump: 0x0100118f
Object id on Block? Y
seg/obj: 0x2e0a csc: 0x00.1c7d1f itc: 2 flg: E typ: 1 - DATA
brn: 0 bdba: 0x1001189 ver: 0x01 opc: 0
inc: 0 exflg: 0

Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0025.00d.00000009 0x02000148.0010.01 ---- 77 fsc 0x0000.00000000
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000

data_block_dump,data header at 0x8732264
===============
tsiz: 0x1f98
hsiz: 0xac
pbl: 0x08732264
bdba: 0x0100118f
76543210
flag=--------
ntab=1
nrow=77
frre=-1
fsbo=0xac
fseo=0x3dd
avsp=0x331
tosp=0x331
0xe:pti[0] nrow=77 offs=0
0x12:pri[0] offs=0x10f9
--=================================
--接下来我们dump上面事务使用的slot信息，slot中stat＝10表示是事务是活动的，slot编号为0x0d
SQL> alter system dump undo header '_SYSSMU37$';

系统已更改。

SQL>
--=================================
Undo Segment: _SYSSMU37$ (37)
********************************************************************************
Extent Control Header
-----------------------------------------------------------------
Extent Header:: spare1: 0 spare2: 0 #extents: 12 #blocks: 95
last map 0x00000000 #maps: 0 offset: 4080
Highwater:: 0x02000150 ext#: 10 blk#: 7 ext size: 8
#blocks in seg. hdr's freelists: 0
#blocks below: 0
mapblk 0x00000000 offset: 10
Unlocked
Map Header:: next 0x00000000 #extents: 12 obj#: 0 flag: 0x40000000
Extent Map
-----------------------------------------------------------------
0x0200009a length: 7
0x020000c9 length: 8
0x02000109 length: 8
0x02000111 length: 8
0x02000119 length: 8
0x02000121 length: 8
0x02000129 length: 8
0x02000131 length: 8
0x02000139 length: 8
0x02000141 length: 8
0x02000149 length: 8
0x02000151 length: 8

Retention Table
-----------------------------------------------------------
Extent Number:0 Commit Time: 1235880926
Extent Number:1 Commit Time: 1235880926
Extent Number:2 Commit Time: 0
Extent Number:3 Commit Time: 0
Extent Number:4 Commit Time: 0
Extent Number:5 Commit Time: 0
Extent Number:6 Commit Time: 0
Extent Number:7 Commit Time: 0
Extent Number:8 Commit Time: 0
Extent Number:9 Commit Time: 0
Extent Number:10 Commit Time: 0
Extent Number:11 Commit Time: 0

TRN CTL:: seq: 0x0011 chd: 0x000e ctl: 0x000a inc: 0x00000000 nfb: 0x0000
mgc: 0x8201 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)
uba: 0x020000ca.0008.0e scn: 0x0000.001c6388
Version: 0x01
FREE BLOCK POOL::
uba: 0x00000000.0008.0d ext: 0x1 spc: 0x1888
uba: 0x00000000.0007.0d ext: 0x0 spc: 0xed4
uba: 0x00000000.0006.04 ext: 0x3 spc: 0x1d8a
uba: 0x00000000.0000.00 ext: 0x0 spc: 0x0
uba: 0x00000000.0000.00 ext: 0x0 spc: 0x0
TRN TBL::

index state cflags wrap# uel scn dba parent-xid nub

stmt_num cmt
-----------------------------------------------------------------------------------------

-------
0x0c 9 0x00 0x0009 0x000b 0x0000.001c6aea 0x020000ca 0x0000.000.00000000

0x00000001 0x00000000 1235881268
0x0d 10 0x80 0x0009 0x0001 0x0000.001c6bba 0x02000150 0x0000.000.00000000

0x0000004f 0x00000000 0
--=============================================
--提交事务
SQL> commit;

提交完成。
--事务提交之后再次dump undo来看事务使用的slot信息，此时发现slot（0x0d）的state＝9，说明事务

已经提交，并且提交时的scn是：001c7f56
SQL> alter system dump undo header '_SYSSMU37$';

系统已更改。

SQL>
--===============================================
Undo Segment: _SYSSMU37$ (37)
********************************************************************************
Extent Control Header
-----------------------------------------------------------------
Extent Header:: spare1: 0 spare2: 0 #extents: 12 #blocks: 95
last map 0x00000000 #maps: 0 offset: 4080
Highwater:: 0x02000150 ext#: 10 blk#: 7 ext size: 8
#blocks in seg. hdr's freelists: 0
#blocks below: 0
mapblk 0x00000000 offset: 10
Unlocked
Map Header:: next 0x00000000 #extents: 12 obj#: 0 flag: 0x40000000
Extent Map
-----------------------------------------------------------------
0x0200009a length: 7
0x020000c9 length: 8
0x02000109 length: 8
0x02000111 length: 8
0x02000119 length: 8
0x02000121 length: 8
0x02000129 length: 8
0x02000131 length: 8
0x02000139 length: 8
0x02000141 length: 8
0x02000149 length: 8
0x02000151 length: 8

Retention Table
-----------------------------------------------------------
Extent Number:0 Commit Time: 1235880926
Extent Number:1 Commit Time: 1235882405
Extent Number:2 Commit Time: 1235882405
Extent Number:3 Commit Time: 1235882405
Extent Number:4 Commit Time: 1235882405
Extent Number:5 Commit Time: 1235882405
Extent Number:6 Commit Time: 1235882405
Extent Number:7 Commit Time: 1235882405
Extent Number:8 Commit Time: 1235882405
Extent Number:9 Commit Time: 1235882405
Extent Number:10 Commit Time: 1235882405
Extent Number:11 Commit Time: 0

TRN CTL:: seq: 0x0011 chd: 0x000e ctl: 0x000d inc: 0x00000000 nfb: 0x0001
mgc: 0x8201 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)
uba: 0x020000ca.0008.0e scn: 0x0000.001c6388
Version: 0x01
FREE BLOCK POOL::
uba: 0x02000150.0011.21 ext: 0xa spc: 0xd08
uba: 0x00000000.0007.0d ext: 0x0 spc: 0xed4
uba: 0x00000000.0006.04 ext: 0x3 spc: 0x1d8a
uba: 0x00000000.0000.00 ext: 0x0 spc: 0x0
uba: 0x00000000.0000.00 ext: 0x0 spc: 0x0
TRN TBL::

index state cflags wrap# uel scn dba parent-xid nub

stmt_num cmt
-----------------------------------------------------------------------------------------

-------
0x0c 9 0x00 0x0009 0x000b 0x0000.001c6aea 0x020000ca 0x0000.000.00000000

0x00000001 0x00000000 1235881268
0x0d 9 0x00 0x0009 0xffff 0x0000.001c7f56 0x02000150 0x0000.000.00000000

0x0000004f 0x00000000 1235882405
--===============================================
--这时候我们再来dump 4495 block来看一下oracle是如何进行delay block cleanout的呢？
我们发现尽管事务已经提交，但是4495 blockitl中显示的状态依然是没有提交时的状态，那么到底什么

时候来清除这个block的事务状态呢？要下一次访问该block时清除，这就是delay block cleanout，这样

做的目的当然是针对大事务加快提交的速度。
SQL> alter system dump datafile 4 block 4495;

系统已更改。

SQL>
--====================================
Start dump data blocks tsn: 4 file#: 4 minblk 4495 maxblk 4495
buffer tsn: 4 rdba: 0x0100118f (4/4495)
scn: 0x0000.001c7d1f seq: 0x01 flg: 0x04 tail: 0x7d1f0601
frmt: 0x02 chkval: 0x9785 type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x08732200 to 0x08734200
...............省去无关信息
Block header dump: 0x0100118f
Object id on Block? Y
seg/obj: 0x2e0a csc: 0x00.1c7d1f itc: 2 flg: E typ: 1 - DATA
brn: 0 bdba: 0x1001189 ver: 0x01 opc: 0
inc: 0 exflg: 0

Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0025.00d.00000009 0x02000148.0010.01 ---- 77 fsc 0x0000.00000000
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000

data_block_dump,data header at 0x8732264
===============
tsiz: 0x1f98
hsiz: 0xac
pbl: 0x08732264
bdba: 0x0100118f
76543210
flag=--------
ntab=1
nrow=77
frre=-1
fsbo=0xac
fseo=0x3dd
avsp=0x331
tosp=0x331
--====================================
--我们来访问一下tt表，由于是count操作，所以一定会scan到4495 block，同时我们观察select操作产

生了redo，这些redo的产生其实主要是清除row的lb（lock byte），当然也要对itl进行修改
SQL> set autotrace on stat
SQL> select count(*) from tt;

COUNT(*)
----------
360192


统计信息
----------------------------------------------------------
1 recursive calls
0 db block gets
5713 consistent gets
0 physical reads
84788 redo size
410 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed

SQL> set autotrace off
SQL> alter system dump undo header '_SYSSMU37$';

系统已更改。

SQL>
--============================================
Undo Segment: _SYSSMU37$ (37)
********************************************************************************
Extent Control Header
-----------------------------------------------------------------
Extent Header:: spare1: 0 spare2: 0 #extents: 12 #blocks: 95
last map 0x00000000 #maps: 0 offset: 4080
Highwater:: 0x02000150 ext#: 10 blk#: 7 ext size: 8
#blocks in seg. hdr's freelists: 0
#blocks below: 0
mapblk 0x00000000 offset: 10
Unlocked
Map Header:: next 0x00000000 #extents: 12 obj#: 0 flag: 0x40000000
Extent Map
-----------------------------------------------------------------
0x0200009a length: 7
0x020000c9 length: 8
0x02000109 length: 8
0x02000111 length: 8
0x02000119 length: 8
0x02000121 length: 8
0x02000129 length: 8
0x02000131 length: 8
0x02000139 length: 8
0x02000141 length: 8
0x02000149 length: 8
0x02000151 length: 8

Retention Table
-----------------------------------------------------------
Extent Number:0 Commit Time: 1235880926
Extent Number:1 Commit Time: 1235882405
Extent Number:2 Commit Time: 1235882405
Extent Number:3 Commit Time: 1235882405
Extent Number:4 Commit Time: 1235882405
Extent Number:5 Commit Time: 1235882405
Extent Number:6 Commit Time: 1235882405
Extent Number:7 Commit Time: 1235882405
Extent Number:8 Commit Time: 1235882405
Extent Number:9 Commit Time: 1235882405
Extent Number:10 Commit Time: 1235883019
Extent Number:11 Commit Time: 0

TRN CTL:: seq: 0x0011 chd: 0x0013 ctl: 0x0014 inc: 0x00000000 nfb: 0x0001
mgc: 0x8201 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)
uba: 0x02000150.0011.2a scn: 0x0000.001c646b
Version: 0x01
FREE BLOCK POOL::
uba: 0x02000150.0011.2b ext: 0xa spc: 0x7c0
uba: 0x00000000.0007.0d ext: 0x0 spc: 0xed4
uba: 0x00000000.0006.04 ext: 0x3 spc: 0x1d8a
uba: 0x00000000.0000.00 ext: 0x0 spc: 0x0
uba: 0x00000000.0000.00 ext: 0x0 spc: 0x0
TRN TBL::

index state cflags wrap# uel scn dba parent-xid nub

stmt_num cmt
-----------------------------------------------------------------------------------------

-------
0x0c 9 0x00 0x0009 0x000b 0x0000.001c6aea 0x020000ca 0x0000.000.00000000

0x00000001 0x00000000 1235881268
0x0d 9 0x00 0x0009 0x000e 0x0000.001c7f56 0x02000150 0x0000.000.00000000

0x0000004f 0x00000000 1235882405
--====================================================
--delay block cleanout之后，我们发现itl中flag为C,LCK=0,最主要是Scn/Fsc＝001c7f56，这个scn是

从哪儿读出来的呢？正是来自undo slot＝0x0d的scn：001c7f56，这个scn正是事务提交时的scn，如果此

时slot被覆盖的话，那么情况将更加复杂。
SQL> alter system dump datafile 4 block 4495;

系统已更改。

SQL>
--============================
Start dump data blocks tsn: 4 file#: 4 minblk 4495 maxblk 4495
buffer tsn: 4 rdba: 0x0100118f (4/4495)
scn: 0x0000.001c8060 seq: 0x01 flg: 0x00 tail: 0x80600601
frmt: 0x02 chkval: 0x0000 type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x08102200 to 0x08104200
..................省去无关信息
Block header dump: 0x0100118f
Object id on Block? Y
seg/obj: 0x2e0a csc: 0x00.1c8060 itc: 2 flg: E typ: 1 - DATA
brn: 0 bdba: 0x1001189 ver: 0x01 opc: 0
inc: 0 exflg: 0

Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0025.00d.00000009 0x02000148.0010.01 C--- 0 scn 0x0000.001c7f56
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000

data_block_dump,data header at 0x8102264
===============
tsiz: 0x1f98
hsiz: 0xac
pbl: 0x08102264
bdba: 0x0100118f
76543210
flag=--------
ntab=1
nrow=77
frre=-1
fsbo=0xac
fseo=0x3dd
avsp=0x331
tosp=0x331
--============================

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/19602/viewspace-1020023/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/19602/viewspace-1020023/

clt3617
关注
macOS Pycharm打开报NSInternalInconsistencyException
quincy_zt941的博客
01-03 2839
macOSPycharm打开报NSInternalInconsistencyException
ORA-002557 archiver error
YOUYOU的小笔记
05-12 630
文章目录问题1：归档空间撑满处理过程问题产生原因问题2：文件系统撑满处理过程问题产生原因 问题1：归档空间撑满 处理过程 2019-05某下午，rac数据库 登陆时报错归档满了，此时应该查询下归档目的地和使用量，确认是否真的满了，也是方便后面分析：当时撑满的原因（是否没有定期删除or这几天的业务量是否导致过多归档）、后续的防范手段。 删除所有归档：（不推荐，万一后面需要做时间点恢复的话就g...
delay block cleanout临界值测试！
clt3617的博客
04-04 134
貌似测的还不够精准，同时没有找到具体介绍10%的相应doc，暂时记录一下。[@more@]SQL> alter system set sga_target=0;系统已更改。SQL> show parameter db...
delayed block clean out不会产生undo
loryliu的专栏
06-30 502
10.2.0.5的库，设置16 select s.name,m.VALUE from v$mystat m,v$statname s where m.statistic#=s.STATISTIC#  and s.NAME in( 'undo change vector size','redo size');
MAB建模规范-Simulink模型建模规范
赞的博客
05-05 6165
规则ID:db、jm、hd、ar被用于Ver 1.0的规范。na和jc用于从版本2.0到现在创建的规范 NA-MAAB代表北美和欧洲。J-MAAB代表日本 目录 Simulink Configuration Parameters配置参数 jc_0011: bool数据类型优化设置 jc_0642:取整模式设置 jc_0806:检测错误计算结果 jc_0021:模型诊断设置 Diagram appearance外观显示 na_0004:Simulink模型外观设置 db_0043:模型字体
Oracle clean out.,Oracle(block clean out)的块清除
weixin_34131379的博客
04-07 158
Oracle(block clean out)的块清除Clean out有2种: fast commit cleanout,delayed block cleanout1.如果一个事务(transaction)修改不超过10%buffer cache的数据块时，oracle做的是fast commitleanout。2.如果一个事务(transaction)修改的块超过10% buffer cac...
定时清理tomcat日志脚本cleanOUT.sh
06-15
定时清理tomcat日志脚本 cleanOUT.sh 每天清理按照每天切割清理,不会用留言,包教会,
Oracle opcode 汇总
renfengjun
11-22 3240
Layer 1 : Transaction Control - KCOCOTCT Opcode 1 : KTZFMT Opcode 2 : KTZRDH Opcode 3 : KTZARC Opcode 4 : KTZREP Layer 2 : Transaction Read - KCOCOTRD Layer 3 : Transa
oracle BBED---数据块浏览和编辑工具 详解
Linucle的专栏
04-12 2659
一，BBED概述 BBED是Oracle 内部使用的命令，所以Oracle 不提供技术支持。 为了安全，BBED设置了口令保护，默认密码为blockedit。 二，BBED的安装和使用 Oracle8i 的BBED在windows 平台下的$ORACLE_HOME/bin下可以找到，9i中似乎未随软件发布，故在windows没有这个工具， 在linux上面有，需要编译。  在9i
oracle_redo_undo
01-08
块清除（Block cleanout）是指清除存储在数据库块首部的与锁相关的信息。我们采用一种无需生成重做日志信息的方式来完成块清除，这样可以省去以后的大量工作。 redo 和 Undo 机制的重要性 redo 和 Undo 机制是 ...
oracle 延迟块清楚,oracle_延迟块清理(delayed block cleanout)
weixin_42364681的博客
04-02 352
此篇文章已经拖了好久，因为是无从下手，看了很多文章和试验很多次，都无法达到理解的情况；在做前面试验时，对data block dump的输出文件ITL.Flag可以看到不同的值；Itl XidUbaFlag Lck Scn/Fsc0x01 0x0008.013.0000024a0x00c00de4.014f.08 C---0 scn0x0000.0022e1a60x02 0x0005...
Oracle block cleanout 说明
ijavagos
08-05 145
一. Block Cleanout 说明 文章的整理参考：http://www.orawh.com/60.html 之前的相关测试参考： OraceITL(Interested Transaction List) 说明 http://blog.csdn.net/tianlesoftware/article/details/6573988 OracleBlock ...
Eclipse Mar 清空控制台/运行中 闪退 MacOs
muzilanlan的专栏
08-16 5095
配置 Eclipse 版本: Eclipse IDE for Java Developers Version: Mars.2 Release (4.5.2) MacOs High Sierra: Version 10.13.6 (17G65) 发生闪退： 清空控制台（clear console） 运行中，打印大量数据时 解决办法 本来我这样的搭配用了也有好一阵子了，最近...
signature=ac75cb7977a45c0f7d8a73dca59a4c27,Mac版闪退
weixin_42412939的博客
05-29 2417
Process: Doit.im [9892]Path: /Applications/Doit.im.app/Contents/MacOS/Doit.imIdentifier: com.snoworange.Doitim-MacVersion: 4.2.6 (41161026)Code ...
busybox 编译mkfs.ext4
Blaider的专栏
05-05 8808
现在主流的android的设备上都是采用EXT4文件系统，所以今天想在NAND上跑一下EXT4。编译完源码，将sbin下的文件全部拷贝到我的SD卡上，然后将SD。 但是不管如何运行都是报:not found的错误。  /mnt/ext # mount -t ext4 /dev/mtdblock3  /usr/ mount: mounting /dev/mtdblock3 on /usr/
升级Mac os x 10.10+xcode6.1之后，Cocoapods出现问题的解决方案
尘雨::执着VC
11-04 9271
在升级Mac OS X 10.10+Xcode 6.1之后，Cocoapods的依赖库管理也相应的进行了升级。目前最新的Release版本是 0.34。在之前的版本中，进行库更新和管理时，会遇到如下错误 /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kerne
快速上手 Rust——实用示例
最新发布
好看资源网的博客
10-28 929
在本节中，我们通过一系列实用示例展示了 Rust 在文件操作、网络请求、并发编程、命令行工具以及数据库操作等方面的应用。通过这些示例，您可以更好地理解 Rust 的特性，并将其应用于您的项目中。在这一节中，我们将通过一系列实用的示例来帮助您更好地理解 Rust 的特性，并展示如何在实际项目中使用这些特性。以下示例将展示如何编写一个简单的命令行工具，该工具能够接收用户输入并执行基本的文本操作。以下是一个简单的命令行工具，它接受用户输入的字符串并返回字符串的长度和反转结果。在这个示例中，我们将使用。
Oracle事务槽(ITL)详解与争用分析
在Oracle数据库管理系统中，事务槽（ITL，Intent To Log）是数据块（block）内部的一个重要组成部分，用于管理并发事务对数据块的访问。当多个事务同时操作同一个数据块时，它们会在事务槽中记录其状态和相关信息，...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值