We went down the role separation path with a grid user for storage/cluster admin that we were going to handover to our unix team and the oracle user for normal DB admin.....It turns out our Unix admins didn't want anything to do with managing ASM or GI so we'd have been better staying with it all under the oracle account. The role separation does cause it's fair share of issues. The listener being owned by the grid user is a particular problem as the oracle user can no longer reconfigure/restart the listener. This breaks a lot of the OEM provisioning functionality and causes problems when attempting to create standby databases...... a lot of manaul work arounds are needed to resolve.
My response to this was:
What he said about "Keep it simple" is right - that principle applies in any case. However just want to clarify on the issue mentioned. A little later after the comment was made, this issue was investigated further in his "My Oracle Support" SR and it was found it was a listener.ora file parsing issue - some spaces were missing in the sid_list_listener entry in the listener.ora file probably because the entry had been manually made. The person concerned himself found this out and fixed the issue. When the extra spaces were added in this line, the file parsed ok. So, there were no real issues with the EM11g Create Data Guard Standby database wizard which he was talking about (this is actually separate from EM11g Provisioning procedures). The EM Create Data Guard Standby database wizard works ok even with role separation with a grid user for the Grid Infrastructure home.
