In my environment I only found a few additional init parameters that needed changing, compared to a single instance to single instance configuration.
These had to be removed or altered when creating the initial pfile for the standby instance.
This one is rather obvious, and must be set to false:
cluster_database = false
These should probably not be configured on the single instance standby:
remote_listener
listener_networks
Similarly, if we're using RMAN to create the standby database, the clone script need to address the same parameters and could look something like this:
DUPLICATE TARGET DATABASE
FOR STANDBY
FROM ACTIVE DATABASE
DORECOVER
SPFILE
SET DB_UNIQUE_NAME='STBY' COMMENT 'standby'
SET LOG_ARCHIVE_DEST_2='SERVICE=PROD ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=PROD'
SET FAL_SERVER='PROD' COMMENT 'primary'
SET CLUSTER_DATABASE='FALSE' COMMENT 'standby is single instance'
SET REMOTE_LISTENER='' COMMENT 'standby is single instance'
SET LISTENER_NETWORKS='' COMMENT 'standby is single instance'
NOFILENAMECHECK;
There is a reasonable overview in the 10g MAA white paper mentioned by Phil. I couldn't find much in the 11g MAA white paper, but it can be worked out from the data guard documentation or simply from trial and error.
Also, I was unable to find references to using the SCAN listener of the clustered primary, so I let the standby instance connect through a dedicated VIP listener, which should be fine. I suppose one might not want data guard traffic going over the public network anyway.