只知道rollback(回滚),没听说过roll forward.

解决方案 »

  1.   

    ROLL BACK(回滚): 
         1、DML操作没有提交,可以手工ROLLBACK
         2、DML操作还没来的及提交,ORACLE非法DOWN掉如SHUTDOWN ABORT或掉电,ORACLE重启时SMON后台进程自动回滚
    ROLL FORWARD(前滚)
         DML操作已经提交COMMIT,ORACLE非法DOWN掉而没发生CHECKPOINT,即在REDO LOG中有,但在数据文件中没有,ORACLE重启时SMON后台进程自动前滚
      

  2.   

    roll forward 和 roll back 都是在数据库恢复时系统后台运行的(但不是后台进程)roll back 是回滚掉redo log里没有提交的数据,在roll back 之前系统会执行roll forward ,我现在搞不清的是roll forward的作用,它和roll back的区别!请各位高手赐教!
      

  3.   

    ROLL BACK(回滚): 
         1、DML操作没有提交,可以手工ROLLBACK
         2、DML操作还没来的及提交,ORACLE非法DOWN掉如SHUTDOWN ABORT或掉电,ORACLE重启时SMON后台进程自动回滚ROLL FORWARD(前滚)
         DML操作已经提交COMMIT,ORACLE非法DOWN掉而没发生CHECKPOINT,即在REDO LOG中有,但在数据文件中没有,ORACLE重启时SMON后台进程自动前滚
      

  4.   

    补充:自动前滚后把在REDO LOG中有,但在数据文件中没有的数据写入DATA FILE。
      

  5.   

    谢谢!
    随便问一下,如果DML操作还没来的及提交,此时在redo log 里是否有记录,有没有可能恢复?怎么恢复?
      

  6.   

    COMMIT是写REDO LOG的充分不必要条件触发LGWR写REDO LOG的条件有四
    1、REDO LOG BUFFER 1/3满的时候
    2、发生TIMEOUNT(我也不太理解这点,是什么TIMEOUT)
    3、DBWR发生时,先触发LGWR把REDO LOG BUFFER中的操作写入REDO LOG,再把DATA BUFFER中的数据写入DATA FILE
    4、COMMIT如果DML操作还没来的及提交就非正常关闭ORACLE,在redo log 里有的操作记录能恢复,否则不能,因为BUFFER里的数据肯定丢失。
      

  7.   

    呵呵
    这个问题和oracle的保障数据不丢失相关因为对于oracle来说
    是否写日志和是否写数据文件是独立的
    当下面几种情况下写日志:
    redo buffer 达到1/3满
    当redo buffer达到1M的时候
    commit的时候
    log switch 的时候
    每隔3秒当发生检查点的时候写数据文件(把数据缓冲区里面的dirty buffer写如数据文件)
    而什么时候发生检查点:log switch
    log_checkpoint_interval = 10000 (日志文件写了10000块,大小是os块,这个参数在8i和8i以前版本的含义又有差异)
    log_checkpoint_timeout = 1800(1800秒)
    fast_star_io_target = 100 (指数据缓冲区写满100块,数据块,db_block_size)
    另外还有一些不常见的参数和oracle在8i以后的一些细节问题
    无法在这里仔细描述
    如果你查阅  恢复原则 ,可能能比较详细的理解在这样的情况下,oracle如果崩溃
    则commit的数据可能还没有写入数据文件(但操作和数据一定写了日志)
    没有commit的数据却有可能已经写入数据文件(操作和数据可能写了日志,也可能没有写)
    那么在oracle重新启动的时候,需要把没有commit的数据剔除
    把commit但没有写入数据文件的补上
    这个时候根据控制文件、数据文件有的  ckpt count 和 scn 来判断决定从日志的哪个地方做实例恢复(详细的内容这里无法仔细论述,还涉及到控制文件的结构和数据文件头结构和日志文件的结构),
    oracle没有仔细去挑这些混合在一起的包含commit和没有commit的数据和操作
    而是统一的根据日志文件做 roll forward,把所有的数据库的操作(已经存入日志的)都做一遍(没有commit的在redo buffer 中还没有写入日志的丢失,但不会有影响,因为commit必然写了日志)
    做完后,然后根据回滚段头的事务表信息(详细的请查阅回滚段部分),把没有提交的事务找出来,然后根据回滚段记录的操作前映像(也就是记录被更新前的状态),进行roll back(回滚段如果损坏可能造成麻烦问题)
    这样oracle保证恢复所有提交数据和剔除所有未提交数据我想,很多细节,当面讲都是很费劲的,这里只能大致提及了
      

  8.   

    各位大侠的理解的真深啊!
    我对这句话还有点不理解
    “做完后,然后根据回滚段头的事务表信息(详细的请查阅回滚段部分),把没有提交的事务找出来,然后根据回滚段记录的操作前映像(也就是记录被更新前的状态),进行roll back(回滚段如果损坏可能造成麻烦问题)
    这样oracle保证恢复所有提交数据和剔除所有未提交数据”
    是否意味着未提交但是已写在redo log 里的数据会被剔除,不能恢复。还有我对如下几个重要参数的理解不知对不对,请各位指教。
    log_checkpoint_interval 是与上一检查点的redo block的间隔,确保恢复的时候读写的redo block 量不超过这个变量指定的数量log_checkpoint_timeout 是与上一检查点的时间间隔,确保恢复的时候读写的redo block 量不超过这个变量指定的数量fast_star_io_target 则是data block经过多少个I/O后产生一个检查点
      

  9.   

    是否意味着未提交但是已写在redo log 里的数据会被剔除,不能恢复。是的,oracle必须保证恢复所有已经提交的数据并剔除所有未提交的数据!log_checkpoint_interval 是与上一检查点的redo block的间隔,确保恢复的时候读写的redo block 量不超过这个变量指定的数量
    ---可以这么理解,不过很多书上只交代对恢复的影响,反而没有交代它本来的含义,本意是这个时候会触发检查点,而检查点信息 (ckpt count)会被记录下来,在日志恢复的时候该检查点以前的日志块就不必使用,所以就造成了这个结果,但事实上这个说法也是不确切的,因为恢复的时候线程是根据日志序号(从数据文件和控制文件得来)找到日志文件,然后再日志文件中根据scn来决定从哪里执行恢复,准确的说是 恢复所使用的日志块数量,而不能说read数量,因为read进内存的数量肯定是要大于等于  恢复是所用的数量的
    log_checkpoint_timeout 是与上一检查点的时间间隔,确保恢复的时候读写的redo block 量不超过这个变量指定的数量
    ---这个不过是从时间上来保障ckpt的间隔不要太长fast_star_io_target 则是data block经过多少个I/O后产生一个检查点---这个参数是当data buffer 中有这么多 dirty buffer产生的时候,就发生检查点,该参数不能超过1000,事实上不管这个参数大到哪里去,1000块脏数据产生的时候数据库一定要发生检查点时间把数据写到数据文件,该参数不能为0。这样的结果就是在恢复的时候,数据库所改动的数据文件中的数据块不会超过这个数字,这也是一个结果,但很多书上就仅仅描述了这点,容易有歧义。 btw:我不理解你的这个说法,怎么要提到i/o?i/o一般就是指磁盘和内存之间的交换,而这里是内存中数据库发生变化。ckpt就是产生write事件的