热备份(hot backup)期间到底做了什么？

biti_rainy

最初由 grassbell 发布
[B]RMAN的热备就取消了 alter tablespace... begin backup; 命令，不必锁定数据文件；而且不会产生多余的日志文件。

这是因为：
RMAN采取了类似于 sql 查询时的一致性读的原理进行热备的，所以不必要在日志中产生整个快的image；并且将开始热备时的scn 记录在rman 目录或者控制文件中，不必要冻结数据文件头。

我的问题：
RMAN采取的一致性读是什么范围的？
整个数据文件？不应该，这样跨越的范围太大，对回滚段的要求太高；

还有，既然RMAN采取 oracle server process 读取数据块，我觉得本身就不会产生split block 的情况。 [/B]

rman 使用了 large_pool_size 进行缓冲，写出之前要再检查 block 的一致性，如果是split  block 则重新读取该块，直到一致为止
实际上一致指的是block

grassbell

最初由 biti_rainy 发布
[B]

rman 使用了 large_pool_size 进行缓冲，写出之前要再检查 block 的一致性，如果是split  block 则重新读取该块，直到一致为止
实际上一致指的是block [/B]

rman 读的时候不是读整个块吗？ 如果是使用的 server process 读的话，应该是读整个block呀，为什么还有split block的情况？

biti_rainy

最初由 grassbell 发布
[B]

rman 读的时候不是读整个块吗？ 如果是使用的 server process 读的话，应该是读整个block呀，为什么还有split block的情况？ [/B]

rman 读的时候依然可能这个块在发生变化，server  process 读难道就能避免吗？  如果正常情况的查询，dbwr 在写入文件的时刻，server  process 在 data  buffer 中就可以得到自然不会去文件中读了 。而只要去文件中读，都可能出现不一致的情况，文件有人在读有人在修改都可能这样的，因为读写并不阻塞，更没有锁定  oracle 的 block

biti_rainy

最初由 Kamus 发布
[B]

server process如何可以知道哪个块是split block？ [/B]

rman 在把数据块写出去之前，会校验块的

如果是普通用户的查询，多个进程对于同一个块的访问，在8i中是串行的，在9i 中也只有 READ & READ 才可以，READ&write 也是串行的。  所以  server  process 读数据的时候肯定不会有 正在发生变化的块

biti_rainy

最初由 Kamus 发布
[B]

其实也就是无所谓校验split block了？
因为当RMAN在写出一个block的时候，这个block一定是一致的
那么是不是可以这样认为，RMAN和老方式热备区别只是在于，前者是oracle用后台process在写出数据文件，而后者是操作系统的命令在copy数据文件。
因为RMAN是oracle在帮你作copy block，所以无需记录整个block image [/B]

rman 本身在备份的时候当然要校验了！
都是拷贝文件

begin  backup时备份进程 自身无法检查block是不是坏块，所以需要冻结文件头并在其他进程读进内存第一次发生改变的时候保存before image。而rman 会及时的校验所以不需要保存before image，同时也不用冻结文件头。

biti_rainy

最初由 Kamus 发布
[B]

都是拷贝文件？
RMAN的机制和操作系统级别copy文件应该差别很大吧

RMAN的校验我想应该只是对于block是否曾经被使用过的检查。 [/B]

是差别很大，rman 是oracle 在自身内部完成的拷贝，所以可以校验。但你的所谓校验 不会说的是 segment 中 HWM 之上的block被算做没使用过吧？还是指增量备份的概念？所以你的 block 是否被使用过是个很模糊的说法，如果是都不是指前面这两个说法，被查询过算被使用过吗？ 被修改过但对于rman拷贝的时候不是 split 的，rman 也能知道，不过并不做特别的处理，只有发现是split的时候才又重新去拷贝。


rman 在 mount状态下可以备份，这就说明rman 只需要知道文件路径然后直接去拷贝文件，当然和简单的 os  cp 有很大的差异了。差异我想我上面都已经说了。

piner

其实，rman只需要保证块是一致的就可以啦
它的拷贝过程就是块的复制过程，所以备份片你可以认为是一个块一个块加起来的，当然，需要另外的块来记录这些块的指针。至于rman的copy，看起来与OS拷贝一样，其实也只是块的复制。

至于所有的块，即不同的块，是可以不一致的，但是有一个条件，就是大于备份开始时候的SCN，假定还没有写入磁盘，则需要在内存中做一致性读。

chenmolin

最初由 biti_rainy 发布
[B]

rman 使用了 large_pool_size 进行缓冲，写出之前要再检查 block 的一致性，如果是split  block 则重新读取该块，直到一致为止
实际上一致指的是block [/B]

   


这个块已经被修改过了，重新读取还是不一致，这里一致性是指这个块读取的时候没有被修改就叫一致性吗。

biti_rainy

最初由 chenmolin 发布
[B]
   


这个块已经被修改过了，重新读取还是不一致，这里一致性是指这个块读取的时候没有被修改就叫一致性吗。 [/B]

一致性 不是说没有被修改，而是说这个块内数据在逻辑上具有一致性，也就是说，若拷贝块的时候碰巧正被写入还没有写入完成的那一瞬间

BTW :   更正一下，没有使用 io  slaves 的时候，rman 是在pga中分配的 cache 而不是large  pool

玉面飞龙

Cache Layer
The cache layer corresponds to the first part of the block header. It contains structures such as:
The data block address (DBA)
The block type (Table/Index, Rollback Segment, Temporary...)
The block format (v6, v7, v8)
A system change number (SCN) used for ordering purposes during recovery
The Cache Layer is 20 bytes and is described by the structure kcbh.
A logical block dump shows most of the cache layer components at the beginning of the dump. The extract below shows the relative DBA (rdba), the SCN (scn), the Sequence number (seq), Flags (flg), and the Block Type (type).

The field Tail corresponds to the last four bytes of the data block, and is used as a sanity check, to detect fractured blocks.

The tail may be referred to as the block footer, and in some documentation as inc/seq. Essentially, the values in the footer match values for structures within the cache layer, and they are updated together. If the footer does not match the cache layer, then an error will result, as the block header is no longer in sequence with its footer.


Start dump data blocks tsn: 4 file#: 9 minblk 5357 maxblk 5358
buffer tsn: 4 rdba: 0x024014ed (9/5357)
scn: 0x0000.000ec539 seq: 0x02 flg: 0x00 tail: 0xc5390602
frmt: 0x02 chkval: 0x0000 type: 0x06=trans data


或许是这个tail检查是否为split block