5M华为云ECS搭建的19c RAC, 某块ASM数据盘大量的读IO（utility100%）,而同一个磁盘组的另一块盘则utility只有20%左右，是什么参数导致了不平衡？ 另外从节点2看到如此大的读IO,在节点1看则IO很小。
从节点2做iostat看到的结果
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdd 0.00 0.00 627.00 2.50 214612.00 24.00 681.93 6.07 9.64 9.66 4.40 0.33 20.50
sde 0.00 0.00 1050.50 7.00 358528.00 45.00 678.15 106.58 100.60 100.53 111.07 0.95 100.00
从节点1做iostat看到的结果
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sde 0.00 0.00 7.50 23.50 92.00 264.00 22.97 0.02 0.55 0.27 0.64 0.55 1.70
sdd 0.00 0.00 2.50 30.50 24.00 202.50 13.73 0.02 0.53 0.20 0.56 0.53 1.75
活跃会话分布
SYS> select inst_id,count(*) from gv$session where username='PLAT' and status='ACTIVE' group by inst_id;
INST_ID COUNT(*)
---------- ----------
1 10
2 23
2 rows selected.
两个块盘（datadg和data2）组成一个磁盘组（datadg），冗余级别是external，这样的话应该是不能在磁盘组做均衡了。
GROUP_NUMBER DISK_NUMBER STATE FAILGROUP PATH
------------ ----------- ------------------------ -------------------- ----------------------------------------
3 2 NORMAL OCRDG_0002 /dev/oracleasm/disks/OCR2
3 0 NORMAL OCRDG_0000 /dev/oracleasm/disks/OCR1
2 1 NORMAL DATADG_0001 /dev/oracleasm/disks/DATA2
1 0 NORMAL ARCHDG_0000 /dev/oracleasm/disks/ARCHDG
1 1 NORMAL ARCHDG_0001 /dev/oracleasm/disks/ARCH2
3 1 NORMAL OCRDG_0001 /dev/oracleasm/disks/OCR3
2 0 NORMAL DATADG_0000 /dev/oracleasm/disks/DATADG
7 rows selected.
SQL> select name,type from v$asm_diskgroup;
NAME TYPE
------------------------------------------------------------------------------------------ ------------------
ARCHDG EXTERN
DATADG EXTERN
OCRDG NORMAL
另外通过索引优化，解决了direct path read的问题，IO也跟着降下来了。
评论
有用 0
活动会话的事件都是direct path read
SYS> SELECT sid,serial#,event,program from gv$Session where username='PLAT' and inst_id=2 and status='ACTIVE';
SID SERIAL# EVENT PROGRAM
---------- ---------- ---------------------------------------- ------------------------------
14 13475 direct path read JDBC Thin Client
15 17040 direct path read JDBC Thin Client
17 53593 SQL*Net message from client JDBC Thin Client
294 12319 direct path read JDBC Thin Client
296 24316 direct path read JDBC Thin Client
297 57213 direct path read JDBC Thin Client
298 55727 direct path read JDBC Thin Client
578 29688 direct path read JDBC Thin Client
580 24614 direct path read JDBC Thin Client
582 62744 direct path read JDBC Thin Client
863 41349 direct path read JDBC Thin Client
1144 54357 direct path read JDBC Thin Client
1427 62112 direct path read JDBC Thin Client
1710 58968 direct path read JDBC Thin Client
1711 61666 direct path read JDBC Thin Client
1993 59893 direct path read JDBC Thin Client
1995 38098 direct path read JDBC Thin Client
1996 53309 direct path read JDBC Thin Client
2279 28913 direct path read JDBC Thin Client
2561 15453 direct path read JDBC Thin Client
2844 683 direct path read JDBC Thin Client
2846 15065 direct path read JDBC Thin Client
3128 34377 direct path read JDBC Thin Client
3408 52108 direct path read JDBC Thin Client
3411 35699 direct path read JDBC Thin Client
3692 23261 direct path read JDBC Thin Client
3693 58684 direct path read JDBC Thin Client
3695 60489 direct path read JDBC Thin Client
3977 61511 direct path read JDBC Thin Client
3978 50359 direct path read JDBC Thin Client
30 rows selected.
评论 有用 0首先：
问题1.需要先确认你举例的两个disk的io不均衡，那这2快disk是什么关系，是否是同一个磁盘组，failgroup 是同一组，还是说normal模式磁盘组，两块磁盘？
假设normal磁盘组，两块磁盘，那么每块磁盘一个failgroup,那么你发起的io很可能在其中一块磁盘，一个failgroup组内，这个时候这块磁盘io很高很正常； 因为normal 两块磁盘，并不能起到asm均衡，只能使用备份高可用的目的。
2.还有就是你的Io高是因为大量直接路径读导致的，那么直接路径读sql读取的tables对于的数据库存储的v$datafile里面的blocks的分布，再去查询asm磁盘组里面的au里面的数据，看看能不能找到对应关系，这样在判断是否真的不平衡。 如果你的asm磁盘是平衡的，但是你的表的数据正好都放到其中一块磁盘，那么就算运气差。
https://www.cnblogs.com/lvcha001/p/14025140.html
3. 还有一种可能性，就是发的链接里面,oracle自身的一些问题，导致某些磁盘存储的数据远远大于其它磁盘，从而导致部分磁盘的io肯定是最高的。
可用看看这个文章
http://www.minniebaby.tech/2022/03/29/%e6%a1%88%e4%be%8b%ef%bc%9aasm%e7%a3%81%e7%9b%98%e7%bb%84%e6%95%b0%e6%8d%ae%e5%88%86%e5%b8%83%e4%b8%8d%e5%9d%87%e8%a1%a1/
评论 有用 0