| RMAN background work [message #490986] |
Fri, 28 January 2011 06:31  |
pokhraj_d
Messages: 117
Registered: December 2007
|
Senior Member |
|
|
Hi,
Its my curiosity , what RMAN will do at the background while taking hot backup.
I am not getting any suitable docs to clear my concepts.
Please help...
Thanks-
P
|
|
|
|
| Re: RMAN background work [message #491024 is a reply to message #490986] |
Fri, 28 January 2011 08:46  |
mmee
Messages: 38
Registered: July 2007
|
Member |
 
|
|
first oracle tool is rman, it's backup utility, whenever we need execute that tool. but hotbackup is totally different it's purely related database writer and OS copy command.
To perform online/hot backup we have to put the tablespace in begin backup mode copying the datafiles and then putting the tablespace to end backup.
One danger in making online backups is the possibility of inconsistent data within a block. For example, assume that you are backing up block 100 in datafile users.dbf. Also, assume that the copy utility reads the entire block while DBWR is in the middle of updating the block. In this case, the copy utility may read the old data in the top half of the block and the new data in the bottom top half of the block. The result is called a fractured block, meaning that the data contained in this block is not consistent. at a given SCN.
Therefore oracle internally manages the consistency as below :
1. The first time a block is changed in a datafile that is in hot backup mode, the entire block is written to the redo log files, not just the changed bytes. Normally only the changed bytes (a redo vector) is written. In hot backup mode, the entire block is logged the first time. This is because you can get into a situation where the process copying the datafile and DBWR are working on the same block simultaneously.
Lets say they are and the OS blocking read factor is 512bytes (the OS reads 512 bytes from disk at a time). The backup program goes to read an 8k Oracle block. The OS gives it 4k. Meanwhile -- DBWR has asked to rewrite this block. the OS schedules the DBWR write to occur right now. The entire 8k block is rewritten. The backup program starts running again (multi-tasking OS here) and reads the last 4k of the block. The backup program has now gotten an fractured block -- the head and tail are from two points in time.
We cannot deal with that during recovery. Hence, we log the entire block image so that during recovery, this block is totally rewritten from redo and is consistent with itself atleast. We can recover it from there.
2. The datafile headers which contain the SCN of the last completed checkpoint are not updated while a file is in hot backup mode. This lets the recovery process understand what archive redo log files might be needed to fully recover this file.
To limit the effect of this additional logging, you should ensure you only place one tablepspace at a time in backup mode and bring the tablespace out of backup mode as soon as you have backed it up. This will reduce the number of blocks that may have to be logged to the minimum possible.
|
|
|
|
| Re: RMAN background work [message #491036 is a reply to message #490986] |
Fri, 28 January 2011 09:23 |
hkchital
Messages: 128
Registered: September 2008
Location: Singapore
|
Senior Member |
|
|
RMAN does not "freeze" datafile headers.
RMAN reads datablocks in the datablock size so it doesn't suffer "fractured" blocks.
RMAN updates the controlfile (and repository if in use) with information about the backups taken, archivelogs expired, archivelogs/backups deleted etc.
Hemant K Chitale
|
|
|
|
| Re: RMAN background work [message #492341 is a reply to message #490986] |
Sat, 29 January 2011 11:00 |
pokhraj_d
Messages: 117
Registered: December 2007
|
Senior Member |
|
|
Quote:RMAN reads datablocks in the datablock size so it doesn't suffer "fractured" blocks
---- Not very much clear about the above quote.
Could you please explain the same?
Regards-
P
|
|
|
|
|
|
| Re: RMAN background work [message #492343 is a reply to message #491036] |
Sat, 29 January 2011 12:40 |
 |
Michel Cadot
Messages: 68732
Registered: March 2007
Location: Saint-Maur, France, https...
|
Senior Member
Account Moderator |
|
|
Quote:RMAN reads datablocks in the datablock size so it doesn't suffer "fractured" blocks.
This is not true.
RMAN read with what IO subsystem allows it: less than a block, equals to a block, equals to several blocks...
It does not suffer fractured block because it checks the tag at the end of read block is the same as the one at the beginning of the block.
Regards
Michel
[Updated on: Sat, 29 January 2011 12:40] Report message to a moderator |
|
|
|
| Re: RMAN background work [message #492348 is a reply to message #492343] |
Sat, 29 January 2011 23:29 |
hkchital
Messages: 128
Registered: September 2008
Location: Singapore
|
Senior Member |
|
|
Any read (whether by RMAN or any Server process) by Oracle is executed by the OS. So, an 8KB read does consist of multiple "Xbyte" blocks from the OS (the OS's filesystem block size could be 512bytes/2K/4K/8K but the underlying hardware sector size could be 512bytes -- so even an OS's read call is multiple sector blocks from the hardware).
RMAN reads an 8KB block the same way a Server Process for a User OR a Parallel Query process reads an 8KB block. In fact, RMAN's read of datablocks is done by Server Processes --- the same as for any user's Server Procsss. The reading is no different.
The advantage RMAN has over non-RMAN (OS based) backup commands is that the others are not "Oracle Block Size aware". These other commands could copy out "fractured" blocks (see "fractured block" in the glossary at "http://download.oracle.com/docs/cd/E11882_01/backup.112/e10642/glossary.htm#BRADV90171"). These OS-based methods do not verify header and footer because they are NOT Oracle Block Size aware -- they do not know where an Oracle Database Block begins and where it ends.
As you point out, RMAN does verify the header and footer of every 8KB block to verify that it is not "fractured". See the third paragraph, beginning with "Unlike user-managed tools,..." in the Online Backups and Backup Mode section at http://download.oracle.com/docs/cd/E11882_01/backup.112/e10642/rcmcncpt.htm#BRADV89479.
The reading of Oracle Data Blocks by checking header and footer is not what RMAN alone does -- every Oracle server process verifies datablocks. The advantage in RMAN over non-RMAN is "being Oracle Datablock aware" by making a read call of Oracle Datablock size.
A database with multiple Oracle Datablock sizes is also handled -- datafiles in tablespaces of 8KB are read with 8KB read calls to the OS (and the header and footer are verified) while datafiles in tablespaces of 16KB are read with 16KB read calls to the OS.
So, comparing the header and footer of an Oracle Datablock is the means of validating an Oracle Datablock read.
RMAN's advantage over non-RMAN methods is that the read is Oracle Datablock size -- which, itself, is implemented by (among other things) comparing the header and footer of the Oracle Datablock.
You are right -- as far as reading the documentation literally goes. My perspective is that the header and footer comparison is inherent in an read by an Oracle server process. My perspective is that RMAN's advantage over non-RMAN methods is that RMAN reads Oracle Datablocks just as any Oracle Server process does --- in Oracle Datablock Size.
Hemant K Chitale
|
|
|
|
| Re: RMAN background work [message #492350 is a reply to message #492348] |
Sun, 30 January 2011 00:59 |
|
Michel Cadot
Messages: 68732
Registered: March 2007
Location: Saint-Maur, France, https...
|
Senior Member
Account Moderator |
|
|
- This does not change a single word of what I have said.
- RMAN processes are different from Server processes.
- "datafiles in tablespaces of 8KB are read with 8KB read calls to the OS", never heard about multiblock reads?
- "My perspective is that RMAN's advantage over non-RMAN methods is that RMAN reads Oracle Datablocks just as any Oracle Server process does --- in Oracle Datablock Size." which could be 2 underlying subsystem IO for one block and so "fractured block". Oracle does not make any assumption how its io requests are served by the OS.
Regards
Michel
[Updated on: Sun, 30 January 2011 01:18] Report message to a moderator |
|
|
|
| Re: RMAN background work [message #492354 is a reply to message #492350] |
Sun, 30 January 2011 01:46 |
hkchital
Messages: 128
Registered: September 2008
Location: Singapore
|
Senior Member |
|
|
In what way are "RMAN processes" different from "Server processes" ?
I do hope that you don't confuse the RMAN Client Process with the Server Process.
Yes, I do know what Multiblock reads are. A 1MB multiblock read of 128 8KB DataBlocks may manifest as a 'db file scattered read'. However, when you are talking of checking the header of a block with the footer of a block, you need to check the header of Block 1 with the footer of Block 1 and the header of Block 128 with the footer of Block 128. Each header-footer check has to be within the single Oracle DataBlock -- whether it be 8KB or 16KB (or 32KB or 4KB or 2KB) in size.
Yes, I admit that "8KB read calls to the OS" wasn't accurate. It is "Read calls of multiples of 8KB -- 1 or more 8KB Oracle DataBlocks in each Read call".
The point of this discussion is about what advantage RMAN has over non-RMAN *backups*. RMAN's advantage in assuring non-fractured blocks is because it handles transfers in Oracle Datablock sizes (and in order to be able to handle Datablock sizes, it has to read and compare header and footer). So "comparing header and footer" is the implementation mechanism for "Datablock size" reads. RMAN's advantage over non-RMAN is "Datablock size".
|
|
|
|
|
|
| Re: RMAN background work [message #492367 is a reply to message #492355] |
Sun, 30 January 2011 07:22 |
John Watson
Messages: 8964
Registered: January 2010
Location: Global Village
|
Senior Member |
|
|
I was under the impression that RMAN channels copy OS blocks, and if it detects that the block was updated during the copy, it will try again. The docs are compatible with this interpretation:
"During an RMAN backup, a database server session reads each data block and checks whether it is fractured by comparing the block header and footer. If a block is fractured, then the session rereads the block." (11.2 B&R user guide chapter 7)
And by the way, it takes a brave man to say this
Quote:I do hope that you don't confuse the RMAN Client Process with the Server Process. to Michel!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: RMAN background work [message #657681 is a reply to message #657680] |
Fri, 18 November 2016 08:59 |
John Watson
Messages: 8964
Registered: January 2010
Location: Global Village
|
Senior Member |
|
|
RMAN operates at the physical level: files, blocks, redo change vectors applied to blocks. You are talking about logical transactions about which RMAN knows nothing.
You could do some reading about the concepts of restore and recovery, it is all in the Backup And Recovery User Guide.
|
|
|
|
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
