| gabriel rosenkoetter on 10 Oct 2003 02:24:02 -0000 |
|
On Thu, Oct 09, 2003 at 10:12:12PM -0400, Beldon Dominello wrote: > Actually, my plan (assuming I wasn't using raw devices, that is) was to have > the backup database server shut down unless it was needed, so it might have > worked if, as I said, the devices were of the cooked sort. Um, but it won't. Because if you start copying files off the live DB while it's still running, by the time you've copied the last file, the first one will have a wildly distant time signature, and Oracle will simply refuse to use the DB files, flat-out. You really do either have to do a hot backup, with archive log mode on, or you have to stop the DB entirely for backup. > Because we want the system volumes in sync as well so that, in case any > changes have been made to system configuration or binaries updated, those > changes would already be in place on the new server. Sure, I could do it > manually, but I'm a lazy sort, and we only have 2 DBAs (and a consultant) to > work with. Have you even considered just using Oracle's clustering environment? It sounds like your application exactly calls for it... > Actually, I've managed to find another software solution which looks ideal. > It's called SteelEye (http://www.steeleye.com) and does OS and data > replication, backup and restore, and failover and is about 1/10th the price > of Veritas, ans supports SuSE, RH, and UnitedLinux. From what I know to be the complexity of doing all those things, never mind doing them all in the same place, this sounds too good to be true. Get a few client references, and find out if it actually works. (And if they can't provide client references, be very suspicious.) Ground-to-heavens reliability solutions usually aren't. Consider how much money you're going to waste finding the holes in this one (or how much *more* money than that you're going to waste when it fails exactly when you need it). -- gabriel rosenkoetter gr@eclipsed.net Attachment:
pgpqUC2sSjJHE.pgp
|
|