Re: Minimizing backup induced downtime

Comments embedded.
On Jul 12, 6: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.
>

Everything? Or everything application-related? I think it's the latter, but please clarify this.

> 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?

Yes, since you are disallowing access to the database during the backup, which isn't necessary for RMAN to complete its job. But you do list valid concerns further down the post.

> 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.

That depends upon when the update/insert/delete occurs and on which table/tablespace is affected. Such changes could very well be in your backup if that backup piece hasn't yet been created. You do have a valid point, however, should this affect a table in a previously completed piece of the backup.

> 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).
>

Now you have a situation where possibly what you are currently doing is a better strategy for your environment than using RMAN would be. Restoring your current snapshots would provide a working database; restoring snapshots created by your second scenario would require a restore and recover operation through RMAN, consuming more time.

> Because of all of this, I'd like to shutdown the application while RMAN
> is running.
>

And that's fine, however I have noted some issues with your proposed backup strategy using RMAN which you won't have with your current method.

> In such a scenario/setup, wouldn't RMAN make the downtime larger?

Yes, both on the backup side and on the recovery side.

> 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?
>

Given your criteria, yes.

> Regards,
>
> Alexander Skwar

David Fitzjarrell Received on Thu Jul 12 2007 - 08:20:31 CDT