点击上蓝字关注我们
某银行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 kfdpDaEv1[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=0x0partner[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有何联系需要深入分析一下。
该阶段的主要作用是制定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 rerbal会根据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 recompacting阶段主要是将磁盘上存的数据尽可能的移动到磁盘的外圈磁道上去，对于机械磁盘，外圈寻址会更快。可以通过隐藏参数对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性能优化，故障诊断，特殊恢复。
推荐阅读：331页！2021年度数据库技术年刊
推荐下载：2021数据技术嘉年华视频回放及PPT下载
2021数据技术嘉年华50余个PPT下载、视频回放已上传墨天轮平台，可在“”公众号回复关键词“”获得！
你知道吗？我们的视频号里已经发布了很多精彩的内容，快去看看吧！↓↓↓
点击下图查看更多 ↓
一个分享交流的地方
长按，识别二维码，加入交流社群