Pat, beg to differ on a fine point. With the Navy, we had a remote replication system, which is how when Katrina pretty much incapacitated our main site, we had data ready to go in our standby site, using data replication. Essentially we did remote RAID-1 type mirroring, but to make that work we had to make the database quiescent so that we could make a point-in-time copy from which to resume operations elsewhere. We learned (the hard way) that ordinary backups were useless for ORACLE. In fact, the sales rep for the replication system swore that it would work without quiescing the system first, but I looked at how it worked and knew that it would not be OK. So (let's call the sales rep "V") V and I made a bet, with me being on the "won't work" side. I won a steak dinner from Cattleman's Restaurant in Ft. Worth because of that. V paid up and I had a GREAT K.C. strip.
For databases that use the "Instantiation Sequence Number" concept as a sort of "Autonumber" that tells you to which generation a table belongs, if you cannot find tables with the same ISN, they aren't synchronized and (at least in the case of ORACLE) you won't "mount" the database. For our tests in October of 1992, I won the bet. But by late August, 2005, we had perfected the process. So when Katrina headed our way, I went to the office on Saturday and triggered a full-on system shut-down followed by full replication. I drove with my family Sunday, and by Monday morning the U.S. Navy Reserve Headquarters Support system was up and running from Ft. Worth - because we took a "point-in-time" remote replication.
If the database engine uses the ISN method of synchronization, I'm pretty sure that your backups will have to be adequate to get you to a "point in time" because of the ISN requirement. Unless ORACLE has moved away from that lately.