Re: Minimizing backup induced downtime

StefanKapitza <skapitza_at_volcanomail.com> wrote:

> On Jul 13, 8:21 am, Alexander Skwar <alexan..._at_skwar.name> wrote:

>> >>>>From where does RMAN/Oracle
>> >>>>pull the data about what has been done between 22:46 and 22:59,
>> >>>>if archive logs aren't available?
>>
>> > The answer to this question is of course: from nowhere.
>>
>> Thanks. So how's that an improvement over doing an EXP?
[...]
> The Improvment was (check your Topic) no Downtime.

Well. But please check my OP, <news:2877861.rzr6KgmIHE_at_kn.gn.rtr.message-center.info>, where I explained that an RMAN backup would mean either having a larger downtime or the odd chance of a user being able to modify something "in between". Let me quote the relevant part:

| 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

If I were just to do an EXP, I also would have no downtime, wouldn't I? I mean, after all a EXP dump can be done while the database is still in production.

The way the application is made, I need to have a downtime, if I want to make absolutely sure that the application is in a consistent state. I don't need a downtime of Oracle, that's true. But I care much more about the downtime of the application then about the downtime of Oracle - especially if the Oracle downtime occurs at the same time, the application is already down.

But currently I'm not doing just an export. I'm doing cold backups and this means a very /short/ downtime. At least in the way it's implemented right now.

| 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 advantage here is, that step 3 is very fast and that step 4 is done in the background, while steps 5 and 6 are already started or completed. As it is right now, I'm doing the exp right before I do step 1. I don't care that much about the EXP being in sync with the application. My real backup is the one I take from the snapshots. Those snapshots contain the database in its shut down state - so it's a cold backup, as far as Oracle is concerned. BTW: As the database is running in archivlog mode, I also archived redo logs which I store as well on tape.

Alexander Skwar Received on Fri Jul 13 2007 - 01:48:34 CDT