How can I maximize the write performance without impacting reads?
Best Answer
A good start is to follow Oracle's SAME methodology - Stripe and Mirror Everything. This gives you a good base from which you can add further more specific improvements.
One of the main drivers for SAME is the ease of administration. It passes on a lot of the performance considerations to the OS and the underlying storage layer. The idea is that your tablespace files are already spread across a zillion disks in the storage array so any fiddling around you do on top of this doesn't help much. However, as ever, the devil's in the detail. It's tempting to treat the storage layer as a black box but you really do need to understand what's going on and know what sits under each of your tablespace files.
LVM is fairly lightweight for just normal volumes (without snapshots, for example). It's really just a table lookup in a fairly small table that block X is actually block Y on device Z. I've never done any benchmarking, but I've never noticed any performance differences between LVM and just using the raw device. It's some small extra CPU overhead on the disc I/O, so I really wouldn't expect much difference.
My gut reaction is that the reason there are no benchmarks is that there just isn't that much overhead in LVM.
The convenience of LVM, and being able to slice and dice and add more drives, IMHO, far outweighs what little (if any) performance difference there may be.
Best Answer
A good start is to follow Oracle's SAME methodology - Stripe and Mirror Everything. This gives you a good base from which you can add further more specific improvements.
The SAME methodology is in the following PDF:
http://www.oracle.com/technology/deploy/availability/pdf/oow2000_sane.pdf
There's a good discussion on Ask Tom:
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:4433784236146
One of the main drivers for SAME is the ease of administration. It passes on a lot of the performance considerations to the OS and the underlying storage layer. The idea is that your tablespace files are already spread across a zillion disks in the storage array so any fiddling around you do on top of this doesn't help much. However, as ever, the devil's in the detail. It's tempting to treat the storage layer as a black box but you really do need to understand what's going on and know what sits under each of your tablespace files.