%util = blkio.ticks / deltams * 100%
deltams is the time elapsed since last snapshot in ms. It uses CPU stats from /proc/stat presumably because it gives better results than to rely on system time,
blkio.ticks is milliseconds spent doing I/Os.
With all allocation unit distributed across all disks due to ASM level stripping,disks were not getting saturated .
Almost symmetrical %util on all disks .
There is a often misconception that something being 100 % is bad and something being 1 % is good. However, such logic may apply to a glass of water that can be full or empty, but does not apply to the performance statistics of a computer.
A CPU for instance can show 100 % and the system may still perform well, or 1 % and perform slow. When something is 100 %, it does not mean the system cannot accept any more tasks, but it means that overall performance when adding more tasks may result in the kernel scheduling tasks at a lower priority, or you may see applications reporting CPU wait times. If you have a bad process, such as an infinite loop, the CPU may show 100 %, and even installing a faster CPU would show the same result.
The percentages are always based on statistics, usually average, and do not reflect whether or not a system is properly configured. The statistics do not tell how well a system can possibly perform, or should perform according to your expectation or the system's technical specifications. It can only show you what it is doing and it is up to you to determine the bottleneck.
What you can say from your iostat output looking at the ASM disks is that the disks were not extremely busy. Btw, there is also a asmcmd iostat utility. So your ASM subsystem is probably not the bottleneck why Enterprise manager reports 98 % I/O activity. How about memory (RAM) and your SGA configuration? For instance, your system may not have enough physical RAM to fit your SGA, swapping will occur which causes a lot of I/O activity and slow down the system drastically.