ASM实验手册22-18_Oracle数据库教程_测试ASM性能与吞吐量Measuring-Throughput
1254
[color=darkred]附：[color=rgb(156,36,35)][font=微软雅黑, 黑体, Verdana][size=20px]关于filesystem与ASM的性能对比
[font=Courier New]如果对filesystem与ASM的区别不太明白，这个贴子值得反复看，老汤简要总结到下面[font=Courier New]这个贴子由一个用户的两个问题引出:
(1), 将RHEL3 32-bit 上运行的一个10.2.0.4数据库迁移到RHEL5 64-bit 后之后,发现一个批处理job慢了10倍(原来5minutes,现在50minutes), 用户查询DBA_HIST_SQLSTAT 发现除了 sql语句的统计数据增量(在两个系统中各取两个快照,相减) 中,除了IOWAIT 之外,其他都差不多, 问tom可能是什么原因导致性能变差,要检查哪些方面?

(2), 一个11.1.0.7的DW系统, OEM显示 read 平均耗时要50ms , 在8个cpu的机器上正在跑12个channel的rman备份,发现cpu load为1, iowait为15%, 看起来 rman在等ASM.
在与系统管理员沟通存储性能问题之前问, tom 要检查哪些方面?[font=Courier New]解决方法:
加大迁移后(ASM) SGA, 比迁移之前(filesystem)要更大[font=Courier New]关于buffered file system与ASM/raw/cluster file system性能对比, TOM的观点总结如下:

[font=Courier New][color=#0080ff]1， 由于secondary SGA的存在, 在从filesystem迁移到ASM时,需要分配更多的buffer cache来弥补ASM中secondary SGA的消失带来的性能损失, 否则系统可能会因此变慢, 因为OS层已经没有cache可以用了;

file system存在TOM称之为'secondary SGA'的现像, 就是说Oracle的server process首先会从SGA的buffer cache中找block, 找不到时,会进行系统调用来'扫描磁盘', 这是站在Oracle的角度看到的,实际上,在OS层面上,会从filesystem cache中找block, 找不到才会真正去进行disk read (实际上,在存储这层,控制器上仍有cache, 而hard disk这层,磁盘头部仍有cache,所以站在不同的层面,说法不一样), 所以TOM说这个file system cache其实相当于Oracle的第二层缓存, 估计这个观点是因为它与 SGA buffer cache一样,都是从物理内存上分配.
[font=Courier New]basically, you used to have a cooked, buffered file system. When you wanted to get a buffer from the buffer cache - and we didn't see it there - we'd issue a physical IO - but it would not be a true physical IO because the operating system would find it in ITS cache - the IO would be really fast because the OS never went to disk.

ASM (like raw, like clustered file systems) do not buffer - not in the OS, not anywhere (a SAN might, but that is a different story). So, the fix? Increase your buffer cache size to make up for the loss of that OS secondary SGA - this will result in even faster performance as we won't have to go to that secondary sga, we just get it from the real one.

2) ASM would not be slow there - once the data is on disk - ASM is really out of the way. The dedicated server reads from disk. If you are seeing really slow IO times - slow read times - it would have nothing to do with ASM at that level. It would have to do with your disk response times.

Do something on them *without oracle*. DD the devices to /dev/null or something and monitor your IO times.
[font=Courier New]2，SGA调整得较好时, ASM性能 > file system性能
因为不必去os cache中查找block( 伴随 context switch等开销,OS要再做一次oracle做的事情, 何况os cache也是以LRU组织,大的表并不总是能cache住, 并且parallel read时,会flush cache,直接从disk读取)，　就是说使用ASM时，不会出现使用filesystem时的系统开销[font=Courier New]在11g时，建议只设置一个内存使用参数，交给oracle去分配pga,sga等;11g之前分配好pga,sga,无特殊情况，不要留太多free memory给os用作filesystem cache，
至于设置多大的sga适合，建议用buffer cache advisor

[font=Courier New]3，存储系统(不是指硬件)选型时,建议使用ASM

(注:上面的ASM可以理解成泛指,TOM其实是说所有非cooked file system,即不存在os 层面filesystem cache的存储组织形式,如raw, 某些cluster file system) [font=Courier New]4，关于OS内存的特性,与CPU这种资源是一样的, free memory不使用时，就会被用作filesystem cache--对于用户来说，相当于"不用即消失"；当进程需要更多内存时，会从filesytem cahce中释放, 所以,给dba的启发是--能用则尽量用[font=Courier New]you don't need to "find it", it is just there - any memory you are not using for something else, the OS will use to buffer the buffered file systems.

If you run a memory intensive program, the OS file system cache will shrink and maybe virtually disappear.

Stop running things that use lots of physical RAM and it'll grow again.

Since memory is a "use it or lose it" resource, like CPU, they use it when it is there and do not when it isn't.[font=Courier New]5 ， ASM中的failgroup其实与redo log中的mirror的原理是一样的, dbwr在写block到ASM时，不会是同步写，而是异步--在适当的时候批量写disk, 并且会等os确认成功, 并且在写镜像的两边时也没有所谓'原子'的概念, 写一侧成功，写另一侧失败是可以的，这也正是ASM failgroup的目的所在![font=Courier New]2) they don't have to be atomic, in fact - one of them can fail (that is part of the purpose). But dbwr would typically do async IO to both devices and wait for the OS to notify it of the completed write.

3) we write in parallel, just like the hardware would be doing. dbwr does this all of the time, even in non mirrored setup. dbwr gets a big set of blocks to write and writes them all using async IO and waits for the "disk device" to tell it "all done"
[font=Courier New]其实tom在这个贴子中的观点要一分为二来看: 如果系统中绝大部分都是physical io,那么,从filesystem迁移到ASM(底层disk 大多是raw,很少直接用block device)后, 不管怎样调整sga,性能都有可能会下降,因为迁移之前filesystem中的cache在ASM中没有了, IO是真正落到了disk上; [font=Courier New]反之,如果不是上面这种情况,那很有可能因为有更多的内存可用于sga,而有利于性能提升,