点击上方蓝字关注我们
某银行ODS系统的一体机(数据库版本为19.8)上，由于某个存储节点掉了4块盘，磁盘处于offline状态，在超过了“_asm_disk_repair_time”时间内没有online，被磁盘组自动drop force，之后在drop disk rebalance未完成的情况下，将4块盘重新加入了磁盘组，由于担心rebalance影响ODS跑批业务，所以在跑批阶段中断rebalance操作，在空闲时重新发起rebalance，反复启停rebalance很多次，但是在某一次中断rebalance之后，发现rebalance就再也无法启动了。
2021-06-30T17:17:21.183103+08:00 SQL> alter diskgroup datac1 rebalance power 0 2021-06-30T17:17:21.186100+08:00 NOTE: cache closing disk 77 of grp 1: (not open) _DROPPED_0077_DATAC1 2021-06-30T17:17:21.186162+08:00 NOTE: cache closing disk 107 of grp 1: (not open) _DROPPED_0107_DATAC1 2021-06-30T17:17:21.186216+08:00 NOTE: cache closing disk 113 of grp 1: (not open) _DROPPED_0113_DATAC1 2021-06-30T17:17:21.186268+08:00 NOTE: cache closing disk 119 of grp 1: (not open) _DROPPED_0119_DATAC1 2021-06-30T17:17:21.187265+08:00 NOTE: GroupBlock outside rolling migration privileged region 2021-06-30T17:17:21.227738+08:00 NOTE: stopping process ARBA 2021-06-30T17:17:25.269379+08:00 NOTE: rebalance interrupted for group 1/0xa1b08317 (DATAC1) ... 2021-06-30T17:18:57.863092+08:00 SQL> alter diskgroup datac1 rebalance power 5 2021-06-30T17:18:57.866314+08:00 NOTE: cache closing disk 77 of grp 1: (not open) _DROPPED_0077_DATAC1 2021-06-30T17:18:57.866376+08:00 NOTE: cache closing disk 107 of grp 1: (not open) _DROPPED_0107_DATAC1 2021-06-30T17:18:57.866430+08:00 NOTE: cache closing disk 113 of grp 1: (not open) _DROPPED_0113_DATAC1 2021-06-30T17:18:57.866482+08:00 NOTE: cache closing disk 119 of grp 1: (not open) _DROPPED_0119_DATAC1 2021-06-30T17:18:57.867615+08:00 NOTE: GroupBlock outside rolling migration privileged region
从日志中可以发现，从17点17分中断rebalance之后，在18分重新发起rebalance，从alert日志以及rbal trace文件可以看到rbal进程再也没有ARBn进程去做rebalance。
仔细的查阅了rebalance相关的后台进程trace以及ASM alert日志都没有任何有用的信息。从发起rebalance命令的进程trace中，发现了非常重要的信息。
ksedsts()+426<-kfnmGroupBlockGlobal()+659<-kfnmGroupBlockPriv()+318<-kfgFinalize()+334<-kfxdrvAlter()+3415<-kfxdrvEntry()+1417<-opiexe()+28735<-opiosq0()+4494<-kpooprx()+387<-kpoal8()+830<-opiodr()+1202<-ttcpip()+1222<-opitsk()+1903<-opiino()+936<-opiodr()+1202 <-opidrv()+1094<-sou2o()+165<-opimai_real()+422<-ssthrdmain()+417<-main()+256<-__libc_start_main()+245 ----- End of Abridged Call Stack Trace ----- Partial short call stack signature: 0xb0ac14de6c5e2e9c SQL> alter diskgroup datac1 rebalance modify power 2 kfgbSendRebalUpdate: xic 2600134044 gn 1 power 2 phase 0 flags 0x1 op=0 NOTE: detected a paused rebalance of group DATAC1 kfgpCreate: max_fg_rel 4, max_disk_part 8 kfgpPartners: NOT appliance. kfgpPartners: max_fg_rel, max_disk_part(4, 8) has been adjusted to (3, 8) due to actual FG, disk configuration (3, 144, num_singledisk_fg 0) kfgpPartner: necessary rebalancing detected. Avail slot for disk120 7 target 8 WARNING: Too many uncompleted reconfigurations. Rebalance needs completion.
从trace的报错来看，熟悉ASM元数据和ASM相关函数的应该知道kfgp开头的都是PST相关的函数，虽然报错相关信息比较陌生，但是至少可以给问题分析确定了一个方向，那就是该磁盘组的pst导致了rebalance无法启动。
回顾一下rebalance和PST的内部原理，思考一下rebalance和PST有何联系。
PST全称叫Partner and Status Table，是ASM的物理元数据，位于ASM磁盘的第二个AU(AU1)，也属于Physically addressed metadata。PST对于ASM非常重要，它记录了该磁盘组所有磁盘的磁盘号、磁盘之间的partner关系、failgroup信息、PST心跳信息以及磁盘状态，磁盘的第二个AU(AU1)为PST保留，但并不是磁盘组内的所有磁盘都有PST，磁盘组冗余级别不同，PST的个数也不同，如下：
External Redundancy一般有一个PST
Normal Redundancy至多有个3个PST
High Redundancy至多有5个PST
详细的PST介绍参考之前的一篇文章https://minniebabylxy.wordpress.com/2021/10/20/asm-physically-addressed-metadata-partner-and-status-table/（复制链接至浏览器浏览），这里就不深入讨论了，主要深入分析一下rebalance。
这里只强调一下PST与rebalance相关的地方，每块磁盘的partner只有20个slot，可以通过kfed或者x$kfdpartner查看每块磁盘的partner关系，如下：
kfdpDtaEv1[1].status: 127 ; 0x030: I=1 V=1 V=1 P=1 P=1 A=1 D=1 kfdpDtaEv1[1].fgNum: 2 ; 0x032: 0x0002 kfdpDtaEv1[1].addTs: 2462919836 ; 0x034: 0x92cd2c9c kfdpDtaEv1[1].partner[0]: 49152 ; 0x038: P=1 P=1 PART=0x0 kfdpDtaEv1[1].partner[1]: 49157 ; 0x03a: P=1 P=1 PART=0x5 kfdpDtaEv1[1].partner[2]: 49155 ; 0x03c: P=1 P=1 PART=0x3 kfdpDtaEv1[1].partner[3]: 49154 ; 0x03e: P=1 P=1 PART=0x2 kfdpDtaEv1[1].partner[4]: 10000 ; 0x040: P=0 P=0 PART=0x2710 kfdpDtaEv1[1].partner[5]: 0 ; 0x042: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[6]: 0 ; 0x044: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[7]: 0 ; 0x046: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[8]: 0 ; 0x048: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[9]: 0 ; 0x04a: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[10]: 0 ; 0x04c: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[11]: 0 ; 0x04e: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[12]: 0 ; 0x050: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[13]: 0 ; 0x052: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[14]: 0 ; 0x054: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[15]: 0 ; 0x056: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[16]: 0 ; 0x058: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[17]: 0 ; 0x05a: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[18]: 0 ; 0x05c: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[19]: 0 ; 0x05e: P=0 P=0 PART=0x0
partner[n]就是partner slot，rebalance时就需要改动partner列表去实现，slot有三种状态：
active：(P=1 P=1)是有效的partner
drop：(P=0 P=1)是解除partner关系
new：(P=1 P=0)是新建立的partner关系
drop和new状态的slot会在rebalance操作完成之后被清理，每块磁盘最多只能有8个active的partner slot。
ASM rebalance就非常常见了，通常是删加盘触发，或者手动rebalance触发，其意义就是让每个文件在ASM磁盘组的所有磁盘上都均匀分配。rebalance操作通常分为3个阶段：
rebalance plan
extent relocating
extent relocating
rebalance的哪个阶段和PST有何联系需要深入分析一下。
1.rebalance plan
该阶段的主要作用是制定rebalance plan，尽可能的将磁盘组中的每个文件在每个磁盘上平均分配。通过打开对kfc(metadata cache)的kst trace深入分析rebalance plan。其实质就是重构磁盘组之间磁盘的partnership，大致也可细分分为2个阶段：
第一个阶段的工作是提供最终有哪些磁盘需要参与此次rebalance，以及每块磁盘当前使用情况，为第二个阶段做准备。
从kfc的kst trace可以发现如下信息：
kfcbpInit: gn=2 fn=2 blk=0 pin=1204 (0x9f3072e8) shar current kffd.c 2109 kfcbpInit: gn=2 fn=1 blk=8 pin=1206 (0x9f3072e8) shar current kfdus.c 620 kfcbpInit: gn=2 fn=8 blk=0 pin=1207 (0x9f3072e8) shar current kfdus.c 649
可以看到依次读取了ASM 2号、1号、8号文件，分别是Disk Directory、File Directory、Disk Used Space Directory。
读取Disk Directory的作用是为了获取磁盘组中所有磁盘的信息(磁盘大小、所属失败组、磁盘状态)等等，状态正常的磁盘都将参与此次rebalance。
读取File Directory的目的是为了获取Disk Used Space Director所在位置。
读取Disk Used Space Director获得每块磁盘当前已使用的大小。
关于Disk Directory的介绍可以参考https://minniebabylxy.wordpress.com/2021/10/21/asm-virtually-addressed-metadata-file-directory/（复制链接至浏览器浏览）
关于File Directory的介绍可以参考https://minniebabylxy.wordpress.com/2021/10/21/asm-virtually-addressed-metadata-disk-directory/（复制链接至浏览器浏览）
第二个阶段的主要工作是根据第一阶段得到的信息去做PST重新配置，call stack为kfgPstPrepare->kfgCanRepartner->kfgpCreate->kfgpPartners->kfgPstUpdate，其目的是得到rebalance plan，保证让磁盘组上的文件平均分布在每块磁盘上，并且需要确保ASM磁盘组的冗余的。同时重构PST需要遵循2个原则，由ASM隐藏参数控制：
每个failgroup只能最多与4个failgroup互为partner
每块磁盘只能最多与其他failgroup中的8块盘互为partner
SQL> @sp partner_target -- show parameter by sp -- show hidden parameter by sp old 3: where x.indx=y.indx and ksppinm like '_%&p%' new 3: where x.indx=y.indx and ksppinm like '_%partner_target%' NAME VALUE DESC ---------------------------------------- ---------- ------------------------------------------------------------------------------------------ _asm_partner_target_disk_part 8 target maximum number of disk partners for repartnering _asm_partner_target_fg_rel 4 target maximum number of failure group re
2.extent relocating
rbal会根据rebalance plan，根据power分配给arbn进程，真正的去做rebalance，该步骤最为耗时，rebalance是按照ASM file分批去做relocate的，每次relocate最多120 ASM file extent，由ASM隐藏参数控制。
SQL> @sp partner_target -- show parameter by sp -- show hidden parameter by sp old 3: where x.indx=y.indx and ksppinm like '_%&p%' new 3: where x.indx=y.indx and ksppinm like '_%partner_target%' NAME VALUE DESC ---------------------------------------- ---------- ------------------------------------------------------------------------------------------ _asm_partner_target_disk_part 8 target maximum number of disk partners for repartnering _asm_partner_target_fg_rel 4 target maximum number of failure group re
3.compacting
compacting阶段主要是将磁盘上存的数据尽可能的移动到磁盘的外圈磁道上去，对于机械磁盘，外圈寻址会更快。可以通过隐藏参数对ASM实例或磁盘组属性去禁用compacting。
SQL> @sp partner_target -- show parameter by sp -- show hidden parameter by sp old 3: where x.indx=y.indx and ksppinm like '_%&p%' new 3: where x.indx=y.indx and ksppinm like '_%partner_target%' NAME VALUE DESC ---------------------------------------- ---------- ------------------------------------------------------------------------------------------ _asm_partner_target_disk_part 8 target maximum number of disk partners for repartnering _asm_partner_target_fg_rel 4 target maximum number of failure group re
通过对ASM rebalance内部原理的解析，回头去看此次案例，问题肯定出在rebalance plan阶段，并且也说明了每一次终止rebalance之后再发起rebalance都要重新经历rebalance plan。核心的报错信息kfgpPartner: necessary rebalancing detected. Avail slot for disk120 7 target 8 ，结合trace里120号磁盘的的PST dump，该报错的含义应该是120的active partner目前是7但应该为8，
disk (0x7f66a40eaa40), num 120a slot 65535 fg 2 ptotal 20 pact 7 pnew 0 pdrp 13
pset dsk 120 [20]: d128fg3 d89fg1 d138fg3 d97fg1 d98fg1 d124fg3 d142fg3 d145fg1 d35fg3 d45fg1 a88fg1 d33fg3 d40fg1 a96fg1 a46fg1 a20fg1 a12fg3 a147fg1 d141fg3 a78fg3
得到的关键信息如下，其中ptotal 20格外显眼，因为partner slot最大就是20：
num 120a：120号磁盘
ptotal 20：已经使用了20个partner slot
pact 7：active的partner slot为7
pnew 0：new partner slot为0
pdrp 13:drop partner slot为13
pset dsk 120 [20]后面的就是partner列表，d128fg3的意思是失败组fg3的128号盘，slot状态为drop a96fg1 的意思是失败组fg1的96号盘，slot状态为active。
那么用kfed去读取一下120号盘的partner列表对比一下发现active partner是8，对比PST dump发现其中一个partner的slot从active变成了drop，就是141号盘。猜测是在PST Prepare阶段取消了141号盘和120号盘之间的partner关系，想新找一块盘来和120组成partner关系，但是由于drop状态的slot在rebalance未完成期间不能清理，而且目前120号盘的PST slot已经用满了，所以报错。
kfdpDtaEv2[42].super.status: 127 ; 0x888: I=1 V=1 V=1 P=1 P=1 A=1 D=1 kfdpDtaEv2[42].super.fgNum: 2 ; 0x88a: 0x0002 kfdpDtaEv2[42].super.addTs: 2456886661 ; 0x88c: 0x92711d85 kfdpDtaEv2[42].super.partner[0]: 16512 ; 0x890: P=0 P=1 PART=0x80 kfdpDtaEv2[42].super.partner[1]: 16473 ; 0x892: P=0 P=1 PART=0x59 kfdpDtaEv2[42].super.partner[2]: 16522 ; 0x894: P=0 P=1 PART=0x8a kfdpDtaEv2[42].super.partner[3]: 16481 ; 0x896: P=0 P=1 PART=0x61 kfdpDtaEv2[42].super.partner[4]: 16482 ; 0x898: P=0 P=1 PART=0x62 kfdpDtaEv2[42].super.partner[5]: 16508 ; 0x89a: P=0 P=1 PART=0x7c kfdpDtaEv2[42].super.partner[6]: 16526 ; 0x89c: P=0 P=1 PART=0x8e kfdpDtaEv2[42].super.partner[7]: 16529 ; 0x89e: P=0 P=1 PART=0x91 kfdpDtaEv2[42].super.partner[8]: 16419 ; 0x8a0: P=0 P=1 PART=0x23 kfdpDtaEv2[42].super.partner[9]: 16429 ; 0x8a2: P=0 P=1 PART=0x2d kfdpDtaEv2[42].super.partner[10]: 49240 ; 0x8a4: P=1 P=1 PART=0x58 kfdpDtaEv2[42].super.partner[11]: 16417 ; 0x8a6: P=0 P=1 PART=0x21 kfdpDtaEv2[42].super.partner[12]: 16424 ; 0x8a8: P=0 P=1 PART=0x28 kfdpDtaEv2[42].super.partner[13]: 49248 ; 0x8aa: P=1 P=1 PART=0x60 kfdpDtaEv2[42].super.partner[14]: 49198 ; 0x8ac: P=1 P=1 PART=0x2e kfdpDtaEv2[42].super.partner[15]: 49172 ; 0x8ae: P=1 P=1 PART=0x14 kfdpDtaEv2[42].super.partner[16]: 49164 ; 0x8b0: P=1 P=1 PART=0xc kfdpDtaEv2[42].super.partner[17]: 49299 ; 0x8b2: P=1 P=1 PART=0x93 kfdpDtaEv2[42].super.partner[18]: 49293 ; 0x8b4: P=1 P=1 PART=0x8d kfdpDtaEv2[42].super.partner[19]: 49230 ; 0x8b6: P=1 P=1 PART=0x4e kfdpDtaEv2[42].siteNum: 1 ; 0x8b8: 0x0001 kfdpDtaEv2[42].spare: 0 ; 0x8ba: 0x0000
这里尝试了使用15195事件设置level 57完全重建磁盘之间的partner关系，报出了隐藏在背后的真正错误，也验证了之前的猜测。
kfgpCreate: max_fg_rel 4, max_disk_part 8 kfgpPartners: NOT appliance. kfgpPartners: max_fg_rel, max_disk_part(4, 8) has been adjusted to (3, 8) due to actual FG, disk configuration (3, 144, num_singledisk_fg 0) kfgpPartners: verifying consistency of newly formed partners. kfgpPartners: repartnering completed. kfgpGet: insufficient space provided by caller. size 21, pcnt 20, KFPTNR_MAXTOT 20 WARNING: Too many uncompleted reconfigurations. Rebalance needs completion.
故障原因：用户频繁的起停rebalance，因为每次启停rebalance都会触发PST重新配置，并且rebalance未完成之前drop状态的slot无法清理也无法重用。
搞清楚故障的来龙去脉之后，解决方案其实很简单，就是drop 120号磁盘。
关于作者
李翔宇，云和恩墨西区交付技术顾问，长期服务移动运营商行业客户，熟悉Oracle性能优化，故障诊断，特殊恢复。
END
推荐阅读：331页！2021年度数据库技术年刊
推荐下载：2021数据技术嘉年华视频回放及PPT下载
2021数据技术嘉年华50余个PPT下载、视频回放已上传墨天轮平台，可在“数据和云”公众号回复关键词“2021DTC”获得！
你知道吗？我们的视频号里已经发布了很多精彩的内容，快去看看吧！↓↓↓
点击下图查看更多 ↓
云和恩墨大讲堂 | 一个分享交流的地方
长按，识别二维码，加入万人交流社群
请备注：云和恩墨大讲堂
点个“在看”
你的喜欢会被看到❤
