在问个redo log 的问题？

NinGoo

最初由 超级野人 发布
[B]我并没有说“rollback的回滚不覆盖”，只是说“发生回滚的可以先把产生回滚的数据块写回disk再覆盖该回滚段” [/B]

我问的是介质恢复的例子，跟buffer写回disk有啥关系

从备份中恢复时，你怎么恢复一个用户rollback的事务？

NinGoo

最初由 超级野人 发布
[B]

8.可能有人要问怎么判断崩溃前有哪些rollback block已经写入disk,有哪些没写？这个可以根据   

rollback block中的scn来判断。因为rollbakc block和data block不一样，一个rollback block只能   

和一个tranction相关联。查找rollback segment file中未提交事务的scn，然后查找有这些scn标志   

的rollbakc block就可以知道需要哪些rollbakc block来进行回滚。在rollbakc block中还会记录有   

与这些回滚信息相关的数据块信息，所以通过这些rollbakc block可以找到相关联的data block。 [/B]

没有redo的保护，rollback block都是些陈旧的信息，你如何判断？

超级野人

最初由 NinGoo 发布
[B]

没有redo的保护，rollback block都是些陈旧的信息，你如何判断？ [/B]

想判断什么呢？

超级野人

最初由 NinGoo 发布
[B]

我问的是介质恢复的例子，跟buffer写回disk有啥关系

从备份中恢复时，你怎么恢复一个用户rollback的事务？ [/B]

呵呵，老兄你说的热备的情景不能算是正常运行状态吧。我想讨论是oracle正常运行时对redo,rollback的策略问题，如果是在热备运行中，我认为rodo中还是有记录rollback信息的必要。但是在非热备运行状态下，我认为不用记录rollback。

freezr

Oracle对待undo block和其它的数据block并没有任何区别，他们的所有变化都会写在redo中，commit的时候只作非常少的工作，所有的脏数据块由dbwr顺序写出，checkpoint定时同步redolog中的变化都被写入数据文件。
我们再看看楼主的思路，undo block与data block区别对待，它的任何变化不在redo中纪录，任何数据写入前都将相应的undo block写入磁盘，恢复的时候，只需要根据redo，恢复data block，然后根据undo作回滚操作。
现在我们作一个比较，我们不讨论很细节的东西，可能这两种做法都是可以的。但是起码我觉得第二种思路更复杂，我们可能需要一个undo cache，用来单独存放undo block，可能还需要一个undo writer，用来保证undo block在data block之前被写入磁盘。其实核心就是是否将undo block与data block区别对待。而且redo中不纪录undo的信息，并没有带来显著的好处。另外一个问题是，undo tablespace需要介质恢复的时候，怎么办？redo中没有纪录undo的信息。
Oracle这样设计不是唯一的设计，但是也许是一个合理的设计。
楼主看来是一个激动的人，每句话都带n个！！！！！

xyf_tck

ORACLE在媒介恢复时必须要根据REDO LOG的记录对数据文件和回滚段都进行重写,只有这样才能对正常操作中的一个ROLLBACK动作进行恢复,也就是在RECOVER过程中必须利用当时重写的数据块和回滚段才能重构出一个当时适用的前镜像来rollback,否则,想仅依靠原来回滚段老的数据是无法实现的,因回滚段是循环使用的,对于已经COMMIT的记录的回滚段是可以被覆盖的,如果存在这种情况,将找不到所需要的数据，RECOVER就无法进行下去。
回滚段的最大的作用不是用在恢复上而是解决了写入器不阻塞读取器，这是其它数据库所办不到的，不能说全是优点，其实各有利弊。TOM的新书上就有一个很好的例子。
另外回滚段应该是有BUFFER的，而且是在产生REDO BUFFER之前就要写入磁盘上的，否则REDO LOG中就无法记录UBA。

leminsky

8楼的statistics，说的好，明白又简单。。

超级野人

非常感谢大家的热烈参与讨论。不过我还是倾向于我愿来的想法：
“redo中不纪录undo的信息，并没有带来显著的好处”我觉得好处挺明显的呀，不记录undo信息，那么log中的信息几乎减少了一半（没有旧值，只有新值），这样l可以大大减轻log write
的负担。

“另外一个问题是，undo tablespace需要介质恢复的时候，怎么办？redo中没有纪录undo的信息。”
  的确是这样，但是我还是那个观点，在数据库策略角度来看，特殊事件需要特殊对待。我想单单恢复undo tablespace没什么意义。肯定是要为了保证数据文件中的数据安全才会需要到undo tablespace。如果数据库是冷备份，那么我觉得undo 信息没有利用价值（数据库都没有打开，备份文件中不可能有需要回滚的东东把？）那么是热备份呢，如果在我的观点来看，同样可以设置某种策略来保证备份的数据文件中不包含可能需要回滚的数据。也就是说：在热备的时候，如果发现该数据文件中有未提交的tranctions的时候，在备份的数据文件中一律使用回滚后的数据，我想这不难办到把？！有人可能要问：如果在热备的时候，这些事务提交了怎么办？在我的策略种：只要在热备开始的时候没有提交的事务一律保存回滚后的数据。如果回滚段被覆盖了怎么办？还是那句话：特殊事件需要特殊对待，在热备的时候不允许回滚段的覆盖。毕竟热备不是经常要运行的吧？赫赫，只要备份的数据文件中没有可能要回滚的信息（不管是热备还是冷备),那么在使用备份数据文件进行数据库恢复的时候，也就不需要回滚段的信息了。

超级野人

在我看来，一个数据库系统应该要保证经那些常要运行的事务运行得尽可能的便捷（比如说log write），而不是保证那些非经常运行的事务（比如热备) 的便捷！如果为了经常运行事务的便捷，可以牺牲那些非经常运行事务的便捷！

NinGoo

数据库首先要保证的是数据的一致性，然后才是其他的。如果数据无法保证一致，那么任何努力都是白搭

其实，oracle现在的体系，很大程度上是由于目前的存储结构，内存速度快，容量小，易失。硬盘速度慢，容量大，非易失。如果有一天，硬盘像内存一样块了，内存就不必要存在了，那么所有的软件来说，其体系就会变得简单很多，oracle也不需要有实例恢复一说了，呵呵


这个问题再争论下去我想已经意义不大了