Re: L:ist - Can do/do better in MS SQL than Oracle

"Howard J. Rogers" wrote:
>
> Were you to stick around for another couple of versions, it wouldn't
> surprise me in the least if you were to hear an announcement that RMAN is to
> be the only supported method of taking backups.

It'd surprise me, at least until they come up with direct, integrated support for disk mirroring/snapshotting solutions (unless that's already in 9i?).

> The push is on (as of 9i) to get people to use it; they've invested heavily
> in simplifying the syntax and making it useable; it's a tool they know from
> the inside, so they know what it is doing. O/S backups, by contrast, are in
> the lap of the gods (well, the mindset of the users, anyway).
>
> I know one 3Tb site using perfectly happily. The performance impact is
> negligible (largely because they limit the I/O rate on the channels doing
> the backup so no-one notices it), and it chugs on in the background for most
> of the day.

So (and I realize you might not be at liberty to discuss much about this particular case if it was a customer, etc.) ... how long did the full backup take (most of the day = 18 hours? More?)? One would assume that the full restore, were it ever necessary, would take equally long, then there's the recovery time (all redo necessary since the backup began = 18 (?) hours worth...)? What did this site do when it came time for patches/upgrades? Most big shops (at least those with a heathly sense of paranoia) take a full backup before beginning a patching/upgrading process. If the process bombs, they revert back to the full backup. Seems like the time involved using RMAN in this manner would be prohibitive. Whereas a traditional hotbackup and a disk split takes far less time to execute (typically on the order of a few minutes to an hour or two to sync up the mirror, then minutes to do the hotbackup and split), far less time to restore (depending on the technology this can range from being nearly instantaneous to a few hours), and far less time to recover (a few minutes of redo to replay).

The same timing issues would arise anytime you needed to clone the database. Seems impractical.

Also, what happens during a "most of the day" backup when a failure occurs (network, instance, disk, RMAN, whatever)? Do you have to start you full backup over from scratch? It seems an awfully long time to be exposed while waiting for the backup to complete... For example, think standby databases - having to wait most of the day to rebuild the standby after switchover/activation.

Finally, limiting the I/O rate on the channels may help I/O issues, but what about cpu usage on the host? Memory? Surely there must be an impact from RMAN. The modern hardware solution has effectively zero impact on the database host's cpu, memory, and I/O except for the few minutes the database is in hotbackup mode. The cpu, I/O, and memory is the storage subsystem's, not the host's.

I'm not trying to undercut RMAN here - like I said I've never used the tool, and from what I've read it does seem to make sense in many environments. But unless it can directly support split-mirroring/snapshotting hardware technologies, I'm not sure I see enough value added for large databases to convince me to switch.

Regards,
Sean Received on Thu Mar 28 2002 - 23:38:05 CST