Re: Minimizing backup induced downtime

On Jul 12, 7:33 am, Alexander Skwar <alexan..._at_skwar.name> wrote:
> Hello.
>
> As you might have noticed :), I'm trying to learn RMAN and am thinking
> about how to use it right for our backups. As it seems to me right now,
> the use of RMAN will make the downtime because of backup *LARGER* than
> it is right now.
>
> Let me explain how I currently do a backup.
>
> 1) Shut down application, which uses Oracle as a backend
> 2) Shut down Oracle
> 3) Create filesystem snapshots with ZFS on Solaris 10
> 4) Start backup to tape of filesystem snapshots. When done, remove snapshots
> 5) Startup Oracle
> 6) Startup application
>
> The step 4 is run in the background. Because of this, the actual
> downtime is very small (a matter of seconds. At most, it's 1 minute).
> I'm currently shutting down everything, so that the files on backup are
> in a consistent state.
>
> I'm now thinking about how to fit RMAN into this picture. I think it
> might look something like this:
>
> 1) Shut down application, which uses Oracle as a backend
> 2) Have RMAN create backup of database
> 3) Create filesystem snapshots with ZFS on Solaris 10
> 4) Start backup to tape of filesystem snapshots. When done, remove snapshots
> 5) Startup application
>
> Here, step 3 is in background. But I cannot start step 3, before step 2
> is actually finished. Because of this, the downtime of the application
> will be larger, won't it? Granted, I don't have to shutdown the
> application, but then I don't know that I'm in a consistent state. Suppose
> that I do not shutdown the app while RMAN is running. Then a user comes,
> adds/deletes/modifies something. This modification is then, of course, not
> part of the backup I'm doing at this run. Even worse - the FS snapshot
> doesn't "harmonize" with what's in the DB (the application creates/deletes
> files in a so called "vault", which is some directory on the server).
>
> Because of all of this, I'd like to shutdown the application while RMAN
> is running.
>
> In such a scenario/setup, wouldn't RMAN make the downtime larger? Or am
> I overlooking something completely (which might of course be true)? Hm,
> right now, I'm pretty much thinking, that a shell script based backup
> (as I'm currently doing) is a better approach, don't you think?
>
> Regards,
>
> Alexander Skwar

If you want to do you can proceed in a similar manner except use rman to do a split mirror backup.

This gets a real rman backup but you can mount the split mirror on a different host and eliminate cpu overhead ( impact ) of rman backup on the server that is hosting the database. Works also with RAC system. It's a very complicated type of backup situation and isn't exactly for the faint of heart but works ok with good documentation. One of the complications ( don't think about this with less than 9.2 my recommendation ) is that the control file you are now operating on in the split mirror isn't exactly the real control file anymore so using a recovery catalog and doing some tricks to get a copy of the control file is also necessary.

Of course you can also do a live rman backup of the real database on the real server(s) with no database downtime while it is running in archivelog mode. In general that's a much less complicated solution but does have cpu overhead on the server(s) where you do the backup.

Whatever solution you choose eventually testing and documentation is vital.

Do you need some specific url referencs to the split mirror backup technique?

Have fun. Received on Fri Jul 13 2007 - 20:15:52 CDT