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

This is interesting info I don't recall ever seeing in any manual. I can remember reading the versioni 7 manuals on this subject - better than taking a sleeping pill :)

But, I thought I learned a fair amount and don't recall seeing this detail.

I assume this type of processing would not have changed since version 7 - correct?

Thanks.

-- 

"Quarkman" <quarkman_at_nowhere> wrote in message
news:3f0487c4$0$730$afc38c87_at_news.optusnet.com.au...


>

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

>

>