I would not even really consider it.

The amount of data transferred using disk based replication on a database is HUGE compared to just shipping redo. Think about it - an insert into a table would:

modify an 8k block of table data
modify at least 3 or 4 other 8k leaf blocks in indexes
generate at least an 8k block of undo data
generate redo to the primary and secondary online redo logs
which eventually turn into your archives

so a single insert could trigger lots of disk to disk based activity. If you used data guard - just the one stream of redo would be sent over. Yes, it is true that a block might be modified many times before being written to disk - but all disk writes of datafiles will be in the block size (typically 8k) regardless of the amount of data modified. It is not unusual for a disk to disk scenario to genearate 7, 8 or more times as much network traffic.

And then there is the fact you have a 'cold' failover site. You cannot use that database on the failover site for anything using disk to disk (except maybe for backing up). No queries, no nothing. In order to failover - you have to script that up.

Data guard was built to easily provide for failover/switchover of your single largest consume of disk - the database. It is what it does.



You use disk to disk for things outside of the database, but to use it for the database - no, I wouldn't do it.