In March, Oracle MAA has published a white paper for implementing Data Guard on Exadata platforms. (http://www.oracle.com/technetwork/database/features/availability/maa-wp-dr-dbm-130065.pdf)

Although the paper is focused on Exadata, some information can be applied to non-Exadata systems as well:

• Corruption Protection:
  • Primary:
    • DB_BLOCK_CHECKSUM=FULL,
    • DB_BLOCK_CHECKING=FULL,
    • DB_LOST_WRITE_PROTECT=TYPICAL
  • (Physical) Standby:
    • DB_BLOCK_CHECKSUM=FULL,
    • DB_BLOCK_CHECKING=OFF,
    • DB_LOST_WRITE_PROTECT=TYPICAL
• Network Tuning:
  TCP Send/Receive Buffers: 3 x Bandwith Delay Product or 10 MB, whichever is greater
• Redo Transport Modes:
  • SYNC is recommended if round-trip-time is less than 5 ms.  Impact of SYNC Mode on primary performance has been improved because local online redo log write and redo shipping is not done sequentially anymore but in parallel.
  • ASYNC: Transport Lag is reduced because Redo is not read from online redo log from disk but from log buffer if possible. init.ora log_buffer might need to be increased for this to yield the maximum benefit.
• LOGGING/NOLOGGING: Normally, in Data Guard you set database-wide “ALTER DATABASE FORCE LOGGING”. In Data Warehouse environments, it might be advisable to set it to NOLOGGING and decide on a tablespace-basis whether the tablespace should allow or disallow NOLOGGING operations. E.g. a tablespace containing only transient, recreatable  or non-critical data might benefit from being set to NOLOGGING for certain bulk operations. (CTAS, Direct Path Inserts, index rebuilds, etc.)
• STANDBY-FIRST Patches: Some patches (PSU, CPU, PSE) will be flagged in the patch README with “Standby-First”. This means that they can be applied on a physical standby before being applied on the primary. For regular patches, this was not supported.