Oracle概念问题假如数据没有提交但是却被dbwn进程写入了数据文件会怎么样呢？
案例分析
首先说明的是dbwn写髒数据跟commit提交没有关系！
在一个transaction发生的过程中online redo log首先记录transaction中修改的数据块相关信息修改的数据块会被缓存在database buffer cache中由于database buffer cache写满或者checkpoint等等条件触发dbwn进程会导致这些缓存的数据块写入数据文件但此时可能该transaction仍然还没有提交所以在数据文件中可能会有commited 和 uncommited 的数据块而原有的数据块镜像会存放在undo segment
IXDBANET社区论坛
然而dbwn写髒数据时不管这个要写的transaction是否提交
也没有必要去管
这样就发生了所谓的已经提交的数据但是还没有写入数据文件的现象
还有一种情况数据没有提交但是已经被写入数据文件此时发生回退撤销没有提交的数据
那么引发Oracle前滚与回退的根本原因就是什么呢？
根本原因是commit后写redo buffer和触发lgwr写 redo buffer的区别
事务在执行完毕后随即会被写入redo buffer和undo中同时在redo buffer和undo中对该事务都有一个是否提交的标记两者的默认状态都是active的即没有提交时刻处于激活状态
commit操作执行时刻把此前的所有事务操作全部写入redo log filecommit成功后redo buffer信息全部写入redo file同时修改两者中的事务提交标识为inactive表示此前事务已经递交
oracle的前滚和回退根据就是依据事务是否提交而进行的
在触发lgwr进程后oracle同样把此前的redo buffer信息写入redo file但是与commit触发写日志不同的是redo file本身对lgwr写日志操作不记录任何信息标识lgwr写到那里就是那里就算此时掉电也无妨redo file就记录到掉电时刻的信息
lgwr是一个Oracle后台执行的进程具体的日志写操作都有oracle去控制这对于oracle来说是透明的因此不用在redo file中写入任何标记信息这也是正常的
commit操作是唯一一个可以前台操作与oracle后台通信的指令因此当加入这个操作以后oracle本身必须要了解各个事务的读写状况那么怎么了解整个状况在redo以及undo中加入是否递交的标识对于已经提交的操作但是还没有写入数据文件那么就要前滚相反对于没有提交执行回退！
于是Oracle崩溃恢复步骤如下
首先rolling forward 前滚由于oracle failuresga中的内存信息丢失了但是online redo log中还是存储了transaction信息包括commited or uncommited data可能这些修改信息并没有被oracle正确的来处理包含两种情况已经提交的还没有写入数据文件或者没有提交的却被写入了数据文件针对已经提交的还没有写入数据文件就要发生前滚在前滚过程中smon会根据online redo log中的记录来完成对datafile的修改保证已经提交的数据已经写入数据文件
接下来前滚结束后数据库正常open此时用户可以正常连接可以访问已经recover的commited data但是对于那些属于unrecoverable transaction的uncommited data会被oracle 加锁是不可以访问的
rolling back假如有进程访问这些加锁的data此时smon会对这些数据块做rollback回滚从数据文件中撤销没有提交却被写入数据文件的数据
