Ask the Expert: Performance Calculations on Clariion/VNX

If you don't need the IOps RAID5 isn't that bad at all. I've even seen log disks that were several hundred GBs in size compared to the db disk which was perhaps 200GB bigger than the log disk, so you simply can't say 1 size fits all. If you don't have bottlenecks now, check (perfmon for example) how many read and write operations as well as the R/W ratio you have.

That's what they told me...

Without this knowledge, I was thinking that FAST Cache could end the discussion about RAID level for log disks... But unfortunately ;-)

Hmmmmm, I'm not aware that FAST Cache should be disabled on the log LUNs. I would expect FAST Cache to be really helpful there as it absorbs excessive writes from RAM cache to EFD drives instead of the slower rotating drives.

Let's check if anyone can help us here: does FAST Cache need to be disabled on LUNs that are used for database logging?

i also heard a little blurb at EMC World  that 5.32 should have enhancements where they detect sequential patterns and don't promote them to Fast Cache.

Ok, avoid RAID5, but that's in an ideal world. I think that calculating the requirements are always better.

That would be wonderful and a real enhancement since then you don't have to worry about either dis- or enabling FAST Cache!

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.

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 ?

50% of DB ? That's insane, none of my multi-terabyte OLTP databases have redo logs that take up 50% of the database size.

you are not confusing redo logs and archive logs ?

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 !!!!

Agreed dynamox, good point!

8.2.3.2 Redo Log Files

If the high-I/O files are redo log files, then consider splitting the redo log files from the other files. Possible configurations can include the following:

• Placing all redo logs on one disk without any other files. Also consider availability; members of the same group should be on different physical disks and controllers for recoverability purposes.
• Placing each redo log group on a separate disk that does not store any other files.
• Striping the redo log files across several disks, using an operating system striping tool. (Manual striping is not possible in this situation.)
• Avoiding the use of RAID 5 for redo logs.

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.

http://docs.oracle.com/cd/B19306_01/server.102/b14211/iodesign.htm

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!?