Re: Hot backup questions

Tablespaces in backup mode are not out of sync, so they have no need to resync when they are taken out of backup mode. Blocks are written to the datafiles during backup mode as they are during normal operation.

If a database crashes or is aborted while a tablespace is in backup mode, there is no need to perform media recovery as prompted by the database during startup. Rather, you can simply query v$backup, and "alter database datafile <'filename'> end backup;" for each file listed there.

So the answer to your problem is that the tablespace never was taken out of backup mode, or got put back in backup mode again before the crash occurred. The instance crashed while in backup mode.

For a full discussion of how backup mode works (freeze checkpoint SCN in file headers, log full blocks to redo), see previous posts to these newsgroups on this very topic. You can see previous postings at deja.com using their power search feature.

It also sounds like your hot backup script could stand some modifications so that it doesn't leave tablespaces in backup mode.

Best of luck,
--
Jeremiah

Doug Cowles wrote:
>
> Couple of hot backup questions.
> I recently had a problem with a hot backup in writting to a tape device,
> and the result was that a tablespace ended up in backup mode for about a
> day. I took the tablespace out of backup mode, and was wondering first
> of all, how I can tell when the underlying datafile is done resynching
> itself.
> One of the reason's being, that when the database was shutdown a full 5
> days later, this particular datafile required media recovery. Now, I'm
> anticipating that some people might think that there was so much
> activity on this datafile that even after 5 days it still had not
> finished resynching, but this is not the case. It is about a 200 MB
> database, (very small), and there was definitely not a great deal going
> on that day.
> So there are two questions - How do I monitor automatic recovery when
> taking something out of backup mode (end backup), and does anyone have
> any explanation for why this would have caused an issue 5 days later.
> Thanks very much,
> Dc.
Received on Mon Oct 25 1999 - 22:55:54 CDT