Home » RDBMS Server » Backup & Recovery » hot backup mode question (oracle 10g, Linux)
hot backup mode question [message #448465] Tue, 23 March 2010 10:38 Go to next message
rajeshkanna.dba
Messages: 16
Registered: April 2009
Location: Bangalore
Junior Member
Hi DBA,

I am little bit confusion regarding begin backup mode(hot backup mode).

1. My query is during backup mode one big transaction is going on what will happen now?

a.) May I know whether the below statement is true or false?

Changes written to redo logs during tablespace backup and changes written to datafile from redo logs after tablespace backup.

b.) Does oracle (DBWR)write to data file while in hot backup mode?(Yes/No)

I referred few of document its confusing me.
Re: hot backup mode question [message #448477 is a reply to message #448465] Tue, 23 March 2010 11:56 Go to previous messageGo to next message
Michel Cadot
Messages: 64102
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator
a) wrong.
Changes are recorded in redo logs and buffer cache (and then into files by dbwr) during backup.

b) yes.

Regards
Michel
Re: hot backup mode question [message #449080 is a reply to message #448465] Fri, 26 March 2010 09:35 Go to previous messageGo to next message
rajeshkanna.dba
Messages: 16
Registered: April 2009
Location: Bangalore
Junior Member
Hi Michel
Thank you for your replay.During hot backup mode The datafile header is frozen, than How the checkpoint is occurring?
Re: hot backup mode question [message #449083 is a reply to message #449080] Fri, 26 March 2010 09:40 Go to previous messageGo to next message
BlackSwan
Messages: 25033
Registered: January 2009
Location: SoCal
Senior Member
>During hot backup mode The datafile header is frozen,
Really? post proof
Re: hot backup mode question [message #449102 is a reply to message #449083] Fri, 26 March 2010 11:45 Go to previous messageGo to next message
John Watson
Messages: 6563
Registered: January 2010
Location: Global Village
Senior Member
Here's how hot backups work.
The problem is that when you copy a file, it will be copied as a series of operating system blocks, typically 1K blocks; but the Oracle block is (typically) 8K. So imagine that the file is being copied and the copy command has copied the first 4 OS blocks of an Oracle block. Then Unix uses its pre-emptive multi-tasking algorithm to take the copy command off CPU, and put the DBWR on CPU. Through bad luck, DBWR decides to take a buffer from the cache, and overwrite the Oracle block. When Unix pre-empitvely multi-tasks the copy program back onto CPU, it continues to copy the block. The copy is useless: it is half one version, and half another. This is knows as a "fractured" block.You might be lucky, and not have any.
When you put a tablespace into backup mode, the redo algorithm is modified. Normally, only the minimal change vector needed to redo work is written to the redo stream, but in backup mode Oracle writes the entire block to the redo stream; this copy will be consistent. If you now restore the file, Oracle will detect the fractured block, and during recovery it will replace it with the consistent version that was saved to the redo stream.
So when you make a hot backup, there will be fractured blocks - but enough information is written out sideways to repair the damage if necessary.
Does this make it clear?
Re: hot backup mode question [message #449104 is a reply to message #449102] Fri, 26 March 2010 11:50 Go to previous message
Michel Cadot
Messages: 64102
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator
Quote:
but in backup mode Oracle writes the entire block to the redo stream;

It does it only the first time you modify the block then it records only the change vectors as in normal mode (not backup one).

Regards
Michel

[Updated on: Fri, 26 March 2010 11:50]

Report message to a moderator

Previous Topic: Backing up Oracle 10g using RMAN & TDP
Next Topic: Recovering lost datafile using OEM
Goto Forum:
  


Current Time: Fri Dec 02 16:33:13 CST 2016

Total time taken to generate the page: 0.42749 seconds