Siguiendo con este articulo, toca detallar la afectación de rendimiento en una BDD al montar un DataGuard y su seguridad de datos (el riesgo de pérdida de datos).

Hay que tener en cuenta que cuanto mas seguridad de datos queramos, mayor será la afectación al rendimiento de la Primay existirá. Así que lo ideal al montar el DataGuard es tener claro cual es la prioridad.
Tranquilos, esto se puede modificar sin problemas ni riesgos.

La diferencia entre un tipo de DataGuard y otro no es mas que el método en que replica los Archivers de la BDD Primary a la StandBy.

Esta configuración se realiza en el fichero de configuración de la BDD StandBy, mas concretamente en el parámetro LOG_ARCHIVE_DEST_2:

*.LOG_ARCHIVE_DEST_2='SERVICE=chicago LGWR ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=chicago'

De este parámetro nos quedamos con el final de la primera línea, donde vemos LGWR ASYNC. Estos campos son los que hacen referencia al tipo de Dataguard que tenemos, o mejor dicho, al modo de transferencia de los Archivers (o Redo Log) de la Primary a la Standby.

En un libro de McGraw Hill (lo siento, no recuerdo cual, solo recuerdo que está en ingles, para variar) encontré una tabla que me guardé como referencia, y que es de lo mas útil para esto:

Veamos las opciones que tenemos para cada uno de los parametros...

- Tipo de escritura de Redo Log

Tenemos las siguientes opciones:
ARCH: Es el valor por defecto. En este caso, el REDO LOG se transmite de la Prymary a la StandBy cuando se hace un switch.
LGWR: Esta opción es nueva en la versión 9i. En este caso, el REDO LOG se va escribiendo simultáneamente en las dos BDD, con lo que no hace falta que se haga un switch de los REDO LOG para que se almacenen estos datos en la Standby (no quiere decir que se repliquen las modificaciones en tiempo real, para eso hace falta algo mas que pondré mas adelante).

- Metodo de transmisión por red

Tenemos las siguientes opciones:
SYNC: Es el valor por defecto. Con esta opción, Todas las operaciones de escritura en el REDO LOG y las operaciones de IO (Input Output) de red se realizan de manera "sincronizada". Esto puede provocar esperas en los procesos que se estén ejecutando en la Primary
ASYNC: Pues lo contrario que la opción anterior... evitando esperas y facilitando la transferencia de los REDO LOG. Esta opción solo se puede usar si el tipo de escritura de Redo log es LGWR.

- Escritura en disco del Archive Log

Tenemos las siguientes opciones:
AFFIRM: Con esta opción, la Primary queda a la espera de que el REDO LOG se replique correctamente en la StandBy. En el caso de REDO LOG muy grandes, puede producir tiempos de espera demasiado elevados.
NOAFFIRM: Es el valor por defecto. En este caso, la Primary no espera confirmación de la copia del REDO LOG a la StandBy.

Hay que tener en cuenta que ninguna de estas opciones garantiza la correcta APLICACIÓN de los REDO LOG en la StandBy. Todas las verificaciones se realizan a nivel de copia y transferencia de los REDO LOG, pero no en su ejecución en la StandBy.

A partir de aquí, solo queda que cada uno decida a que dar prioridad.

Espero que sea de utilidad.