Dennis is certainly correct to point out that a backup scheme -- whatever one you go with -- should be requirements-driven.
That said, it is very important to ensure that your decisions are being driven by the
right requirements.
Now, I have no knowledge whatsoever of your requirements-setting process, but the little that I have seen here shows a great deal of consideration for
backup
requirements, and relatively little for
recovery requirements. Let's get one thing straight right from the start: this process is about
recovery
, not backup, although there are requirements specific to each that you need to consider.
Split-mirror backups are pretty cool. In the early-to-mid '90s (and maybe even the late '90s) this was considered the "Cadillac" solution for database backup. I do hope that you're not doing true "split-mirror" backups these days, though, since almost every storage vendor out there now offers much better methods for doing roughly the same thing. (The terms "BCV", "Snapshot", and "Flashcopy" leap to mind, although each vendor generally coins their own terminology, so the equivalent for you storage platform may be called something slightly different.) But I digress...
The point here is that your focus should not be nearly so much on "backup" as on "recovery". This is especially true in the context of "disaster recovery".
Now, I am not going to try to tell you here what your requirements are -- or even what they should be. There are, however, a
few things that your organisation might want to consider (if they have not already).
- recovery should be achieved with the fewest personnel, and the fewest special skills, and the smallest amount of specific knowledge possible. (Hint: in a DR scenario, your sysadmins and DBAs may all be dead or incapacitated!)
- recovery procedures should be simple. Ideally, they will be completely automated. Recovery operations tend to be stressful at the best of times. And you have no control of when they will happen. Unless you, your sysadmin, your storage administrator, your operations, your ... are all teetotalers any or all could be drunk or hung-over when called upon to serve. Ideally, the recovery procedure should be simple enough that it can be completed with a reasonable expectation of success even in the middle of the company christmas party when you, your sysadmin, and your lead operator have just finished the 12th round in a shooter contest...
- Recovery procedures must be timely. They must not just fit within your maximum allowable window, they must minimize (or avoid) downtime as much as posible. Your DR requirements may allow you 4 days to restore service at your standby site, but your CIO won't be happy if you need even (only!) 3 hours of downtime to require a corrupt block.
Now, there
are a few backup requirements to consider, too:
- Backups should not cause unnecessary downtime. (You seem to have that covered.)
- Backups should not needlessly (not unacceptably) impair production performance. (You're probably okay on that, too.)
- You want to leverage backups as much as possible -- for example, discovering corrupt database blocks while performing backups.
- You need adequate backup retention. (I've seen sites that are very serious about DR that retain backups for as little as 5 days; done right, I cannot see any reason to retain backups for less than 90 days.)
- You want to minimise capital costs. Making (and retaining 90 days' worth of) daily full backups can be many times more costly than that for a well planned scheme of incrementals...
Anyway, I've said a lot, but so far nothing specific to the original question of RMAN vs. split mirrors. I don't plan to ignore that question, but the hour is late, and I need to to go work (you know, that place where they *pay* me to answer questions) in the morning. I'll try to offer some more specific comments on this subject tomorrow -- hopefully when I do, it won't look like the time I spent typing this response was wasted...
--
Cheers,
-- Mark Brinsmead
Staff DBA,
The Pythian Group
http://www.pythian.com/blogs
