Re: What *really* happens at ALTER TBSP END BKP ?

"Spendius" <spendius_at_muchomail.com> wrote in message news:aba30b75.0307031110.1c79e4bf_at_posting.google.com...
> Hi,
> When you put a tbsp in bkp mode, to copy its datafiles during
> a hot bkp, Oracle writes anything that should be written on
> them in the redo log files: is that all ? Are the rollback
> segments not written during the bkp mode duration ? And what
> happens when it comes to the RBS tbsp ?
> And last but not least: once you've taken your tbsp back to
> normal online mode (ALTER TBSP .. END BKP), I guess Oracle
> updates this tbsp's datafiles right away, doesn't it ? How
> is this very step performed ?
>
> I found no clear-cut explanation in the doc., hence my question...

There have been several on the web!

Putting a tablespace into hot backup mode does not alter in any way Oracle's normal mode of operation. Data files are written to by DBWR, redo logs by LGWR, rollback segments are modified exactly as they would be without hot backup mode.

The important point there is that the contents of the datafiles are modified normally throughout the hot backup. Updates to data aren't 'cached' somewhere for the duration, and then applied in bulk at the end of the backup. That would be a recipe for disaster, and it's *not* what happens.

All that happens when you say 'begin backup' is two things (apart from causing a checkpoint to take place for the affected tablespace):

1. some bytes are modified in the controlfile that indicates that CKPT is not to update the SCN in the header block of the datafiles for the tablespace being backed up.
2. those same bytes also tell all server processes: if you are the first server process to modify a block within the tablespace being backed up, do not just write the normal amount of redo (which for a typical update is just a few hundred bytes, probably), but write the *entire* block into the redo stream... that's 8192 bytes for an 8K block system, more if you've chosen a bigger block size, obviously.

And that's it.

It does (1) because there is no guarantee when the O/S will get around to backing up the datafile header block, but for successful recovery, Oracle has to know the earliest possible time from which redo needs to be applied. The only way that can be done is by artificially freezing the 'time' of the header block by not letting CKPT update it. The *contents* of the datafile will change as per normal, but the header block will indicate the time the file began to be backed up.

It does (2) because an Oracle block is composed of lots of individual O/S blocks, and there is no guarantee that the O/S will copy them when they are all at the same SCN time, precisely because the contents of a block are indeed being modified whilst it's being copied. Copying different bits of an Oracle block at different SCN times would result in what's known as a 'fractured block'. So the first piece of DML that affects a block cause an entire image of the block to be put into the redo. The real block can now fracture as much as it wants to... we have a consistent image of it in the redo logs to which all future DML can be replayed.

Note, however, that it's only the first piece of DML affecting a block that causes the whole block to be written to redo. Second and subsequent updates generate only the normal amount of redo.

Given all that, it's obvious what happens when you say END BACKUP. Bytes are modified in the controlfile telling CKPT that it's OK to update the header block's SCN, and which tell Server Processes not to bother writing entire blocks to redo. And again, that's all it does.

In particular, END BACKUP does *not* cause a checkpoint to be issued, and does not therefore bring the SCN of the tablespace back into synchronisation with the SCN in the headers of all other datafiles. Many books reckon you should issue an 'alter system switch logfile' or similar just after the END BACKUP command, because only then are the various SCNs synchronised, because of the system-wide checkpoint that command causes. But there's really not a lot of point, since if you just wait long enough, another checkpoint will take place naturally anyway. (It is true, however, that until the headers are synchronised, you are a little vulnerable to an unexpected instance failure... Oracle would demand you perform a media recovery on subsequent startup to correct the SCN mismatch, when in fact no real media recovery is required). Assuming you don't suffer from instance failures on a regular basis, however, the extra checkpoint those books recommend is a bit unnecessary.

In short, it's all to do with datafile *headers*, and nothing at all to do with datafile *contents*.

~QM

> Thanks !
> Spendius
Received on Thu Jul 03 2003 - 14:45:11 CDT