在问个redo log 的问题？

frogprince-erp

看看

超级野人

最初由 超级野人 发布
[B]其实我要问的就是：假设一行数据被修改了，那么修改后的值和修改前的值都会保存在日志文件中，对巴？而修改前的值也会保存在回滚段中，所以我感到疑惑：即然回滚段中已经保存了旧值，为什么在日志文件中还要再保存一次旧值呢？如果是为了保障数据的安全，那完全可以在数据写回硬盘的时候，先将与该数据相关的回滚段信息先写入硬盘的么！这样一来，在写数据之前，已经可以保证新值（在日志文件中）和旧值（在回滚段中）都安全的写回硬盘了呀！从而保证数据的安全！！ [/B]

如果oracle是按照我这个模式运行，有什么问题么？也就是说对回滚段的修改不记录在日志中，在恢复的时候，难道oracle要看日志才知道哪些tranction要回滚么？我觉得在rollback段中也应该记录有这些信息把！！！！！

NinGoo

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

如果oracle是按照我这个模式运行，有什么问题么？也就是说对回滚段的修改不记录在日志中，在恢复的时候，难道oracle要看日志才知道哪些tranction要回滚么？我觉得在rollback段中也应该记录有这些信息把！！！！！ [/B]

你要明白，回滚段的修改也是在buffer中完成的，如果没有redo的保护，实例崩溃时，那些还在buffer中没来得及写入到datafile的回滚段信息就会丢失，那么实例恢复的时候，如何回滚那些回滚信息已经丢失的事务？

NinGoo

最初由 超级野人 发布
[B]为了保证write to disk过程中数据块中数据的安全，完全可以在写data buffer的时候，先写入与该数据块相关联的rollback segment  buffers么！ [/B]

当然也可以通过commit时将回滚段先写入datafile的方式来保证事务的一致性，但是，这样一来，可能用户发出commit命令后，过了10分钟也未必能得到提交完成的反馈。你看看dbwn和lgwr的写策略，看看buffer cache和redo buffer的大小就能明白为什么

到罗马的路有很多条，但每条路的代价是不一样的

超级野人

最初由 NinGoo 发布
[B]

你要明白，回滚段的修改也是在buffer中完成的，如果没有redo的保护，实例崩溃时，那些还在buffer中没来得及写入到datafile的回滚段信息就会丢失，那么实例恢复的时候，如何回滚那些回滚信息已经丢失的事务？ [/B]

不知道大家看清楚我的方案没有，按照我的方案，脏数据在写入disk之前先写与之对应rollback记录，如果rollback记录没有写入disk，那么也就表示没有与该rollback相对应的脏数据写入disk，也就不需要回滚呀！！！！！

超级野人

最初由 NinGoo 发布
[B]

当然也可以通过commit时将回滚段先写入datafile的方式来保证事务的一致性，但是，这样一来，可能用户发出commit命令后，过了10分钟也未必能得到提交完成的反馈。你看看dbwn和lgwr的写策略，看看buffer cache和redo buffer的大小就能明白为什么

到罗马的路有很多条，但每条路的代价是不一样的 [/B]

我的方案并不是说commit时要写入回滚段呀，只是说在写脏数据前先写与之对应的rollback。而且因为我在日志中不写入rollback的信息，因此日志内容更少，所以commit的速度也就越快！！！！写脏数据和写日志(commit)并不是一个同时发生的事情把！！！！？？？

NinGoo

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

我的方案并不是说commit时要写入回滚段呀，只是说在写脏数据前先写与之对应的rollback。而且因为我在日志中不写入rollback的信息，因此日志内容更少，所以commit的速度也就越快！！！！写脏数据和写日志(commit)并不是一个同时发生的事情把！！！！？？？ [/B]

问题还是在于实例崩溃/实例恢复的时候

如果redo不记录undo block的变更，那么实例崩溃时，buffer中尚未写到datafile的undo block就无法恢复出来，没有这些undo,那对应的事务就无法回滚

超级野人

最初由 NinGoo 发布
[B]

这个我前面已经解释过了，oracle目前的机制，之所以commit时能够只写redo，正是因为redo记录了buffer中所有的change，不管是data block还是undo block

如果按你的方法，data block由于有redo的保护，在commit时只要redo写完就能保证其可以恢复，,undo block没有redo保护，那实例崩溃后这些undo block如何恢复？没有这些undo ，那么对应的没有提交的事务该如何回滚？所以如果redo不记录undo block的变更，那么commit时就必须将undo block写回到datafile中

总之一句话，undo block也好,data block也好，正是由于他们都在buffer中进行修改，就必须记录redo，否则，实例崩溃后,buffer中的所有信息都丢失，你必须有一种机制能保证实例恢复时，能将崩溃前的buffer信息复原 [/B]

崩溃后还要恢复所有的undo block？有必要么？我们假设某个tranction还没commit数据库发生崩溃。（已commit的tranction我就不讨论了），这个时候假设该tranctons的脏数据有部分已经写入disk,有部分没写。同理，有部分undo block已经写入disk,有部分没写。那么还要恢复那部分没来得及写入disk的undo么？我看没必要吧，因为部分脏数据没有写入disk，因此disk上面的数据还是old的，不需要回滚。只有已经写入disk的脏数据才需要回滚！！而这部分数据的回滚也只是需要已经写入disk的undo block。(因为undo block 总要在trange block write to disk之前write to disk）

NinGoo

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

崩溃后还要恢复所有的undo block？有必要么？我们假设某个tranction还没commit数据库发生崩溃。（已commit的tranction我就不讨论了），这个时候假设该tranctons的脏数据有部分已经写入disk,有部分没写。同理，有部分undo block已经写入disk,有部分没写。那么还要恢复那部分没来得及写入disk的undo么？我看没必要吧，因为部分脏数据没有写入disk，因此disk上面的数据还是old的，不需要回滚。只有已经写入disk的脏数据才需要回滚！！而这部分数据的回滚也只是需要已经写入disk的undo block。(因为undo block 总要在trange block write to disk之前write to disk） [/B]

没有写回disk的data block，在实例恢复的前滚阶段，已经通过redo恢复到实例崩溃前的状态了，这时发现事务未提交，需要回滚，那么没有对应的undo，如何回滚？

NinGoo

实例崩溃是先前滚，再回滚的

oracle如何判断实例恢复时一个事物是否已经提交？根据redo的信息，所有只有在应用所有redo后才能判断一个事物是否已经提交，应用完所有redo后，原来buffer中所有的data block都已经恢复到崩溃前的状态了，这个时候再来执行回滚，当然也就需要崩溃前所有的undo block