Recovering from Oracle host OS disk failure (options)

It really is to be the number of physical disks, in the old fashioned style, not using a SAN. The best article about this I found here http://blog.bensmann.com/testing-oracle-io. Most others blogs/docs I found were more like copies from manuals than original contents that explains something new. When using this on a SAN, the cache is going to play a big role, as is the inner working of those beasts. For example, they write in a buffer and give an acknowledgement to the rdbms that the write is complete, even when the data did not even come close to the intended disk. When continuously other blocks are written, that cache could be choked and then we get a better view of the real io performance. Reading and updating blocks from a regular sized datafile won't be sufficient to reach that.

There is no need to copy the files - there is an ASM "trick" that does exactly what you want to do with no interruption in service. When ASM rebalances a disk, it maintains a list of viable LUNS for each block independently of the LUN on which it presently lives. It also won't drop a disk on which there are active blocks without rebalancing elsewhere - but it will mark it as not a viable home for rebalancing!

Once you have used oracleasm to make the new LUNs visible to ASM, you just issue the single command (forgive syntax, off the top of my head)

alter diskgroup my_dg add disk 'new1', 'new2', 'new3' drop disk old1, old2, old3;

Then sit back and wait. ASM will hot-relocate each block from the old storage to the new, laying them out nicely on the way, and drop the old disks when the operation completes. I/O will be a bit higher, but your users probably won't notice a thing.

As for your ORACLE_HOME, I'm afraid switching that will require a (brief) outage.