Redo log files are written sequentially by the Log Writer (LGWR) process. This operation can be made faster if there is no concurrent activity on the same disk. Dedicating a separate disk to redo log files usually ensures that LGWR runs smoothly with no further tuning necessary. If your system supports asynchronous I/O but this feature is not currently configured, then test to see if using this feature is beneficial. Performance bottlenecks related to LGWR are rare.
Yeah, but I'm then also wondering whether redo logfiles should actually be put on RAID5 instead of RAID10. Remember that full stripe writes on RAID5 are cheaper than writes on RAID10. So there the move to RAID5 would actually improve back-end load!?
if you are going to dedicate one raid group for specific server, probably yes. But considering how small redo log files are, storage admins like to put multiple server's redo log files on the same RG/Pool. So multiple sequential streams become random writes as far as RG/Pool is concerned. Agree ?
Like I said before, redo logs don't have to be small: I've seen db servers with database drives of 500GB and redo log drives of 250GB !!!!
50% of DB ? That's insane, none of my multi-terabyte OLTP databases have redo logs that take up 50% of the database size.
I know…. These were high I/O OLTP of a University Hospital and they wanted to make sure the transactions were saved (for 2 days I think it was) even without the hourly backup.