Do you experience any redo log writer issues?

As EMC best practice and test report, redo log write in most scenarios are able to handle with VNX SP write cache, because the pattern of redo log write is small seq write.

EFD might not a good option to Oracle Redo on Storage. Please look at this discuss. https://community.emc.com/message/615475#615475

Though SSD is not typical for small seq write, it is great for high-bandwidth I/O components such as Oracle redo logs. Some test showed when you are not CPU constrained, moving the online redo to high-speed solid-state disk can make a difference. Certainly the price is a difference also.

What is the raid type of your REDO luns? how many disks do you configure for REDO?

It will be good if you can provide the AWR report, we can look into the redo size and transaction commit frequency etc.

For the database background event "log file parallel write", it should be no more than 15 ms for a accptable perfomrance.

Hi Charlie, the RAID type does provide balance of system reliability and performance.  RAID 1 or 0+1 are recommended to achieve optimal redo log performance in additional to good system reliability

Do you customer explain anything about performance?

Redo commitment commit frequently, that does not mean performance issue, might be requirement of application logic. That happens in billing, FR system

I wrote a blogpost on redo log performance as this is a recurring topic in many customer discussions.

Disclaimer: not everyone might agree with my statements (but I guess that's normal when discussing performance stuff )

Bottom line is that storage cache should handle all redo writes, therefore your response time should be very low (if not, something is wrong). RAID-5 should be fine for performance as redo log writes almost 100% sequential which is very spinning disk friendly. IMO the only reason to have RAID-1 for REDO is availability (another discussion) and (maybe) if you have very excessive write workloads.

But having other data (TEMP, DATA, INDEX, etc) on the same physical disks as the REDO logs breaks the whole thing (disks start doing random seeks and this slows down REDO updates, and the REDO updates then cause high disk utilization which slows down random reads for DATA in return). Hard to diagnose.