>>> >>>So from corruptions perspective - a storage level replicated >>>database IS as single point of failure. Not to mention that >>>all user errors such accidential rm -rf * get all propagated >>>to remote storage without a question. Tanel, your input is always golden, but I don't think the SAN replication proponents (like me) are suggesting a single-technology approach. There still has to be thought about logical corruptions as you point out, and human accidents like rm(1) as well need to be factored in. I think storage-level replication combined with an amount of local Data Guard and perhaps filesystem snapshots can help. For instance, our next filesystem release will support a non-intrusive snapshot capability that will allow you to snapshot filesystems not just every now and then, but hundreds of thousands of times. That would take care of rm(1) concerns because the database in a filesystem snapshot looks just as it would if you had powered off the system. So you could mount a snapshot that is, say, 30 seconds old and roll it forward. I know, I know, I'm talking about some technology that doesn't come on a CD from Oracle Corp so it can't possibly be helpful right ? :-) Where I sit, the intent is to solve this problem in a way that is not Oracle-centric but will have Oracle in mind, and from a market persective, I think that is anything but a foolish approach. DR threads are always very healthy for the mind and if anything can be stated matter-of-factly regarding DR, it is that you better not approach the problem with a religious brain-washed bias or the project is doomed. Any input from Carel-Jan on this sort of thread is gold as well. In the end, it really does have to start with RTO/RPO analysis as Carel-Jan states a few posts back. If RTO/RPO can be established the project might at least be more feesible than trying to make brick without straw. -- //www.freelists.org/webpage/oracle-l