提交和dbwr没有任何关系,物理读产生逻辑读,快照过旧的理解

  
  

  提交仅仅是触发把日志缓冲数据写入在线重做日志并且把提交了数据的事务的将记录在控制文件中,注意此时的数据文件中的scn没有变化,
  
  DBWn过程将脏缓冲区写入磁盘在下列条件:
  ——当一个服务器进程无法找到一个干净的可重用的缓冲后扫描阈值的缓冲区,它信号DBWn写作。异步DBWn将脏缓冲区写入磁盘如果可能在执行其他处理。
  ——DBWn定期将缓冲区写入推进检查点
  在以下条件下,DBWn进程将脏缓冲区写入磁盘:
  当服务器进程在扫描阈值数量的缓冲区之后找不到干净的可重用缓冲区时,它会将DBWn发信号写入。执行其他处理时,如果可能,DBWn将异步缓冲区写入磁盘。
  定期写入缓冲区以推进检查点
  
  <强>所以提交和Dbwr没有任何关系
  (当事务修改数据时,,如果事务没有提交,则标记段头部为ITL,如果提交,则把提交时刻的SCN写入数据块中,回滚的时候根据段是否提交来定位,如果没有承诺就直接找到撤销中这个会话最初的视交叉上核和前镜像直接回滚,不会一个个数据块去撤销,否则10 g都已经写入数据文件那回滚得多久啊)   

  实验过,10 g容量级别的大量插入操作了30分钟,但是不提交,会发现重做日志不停的切换产生归档日志,且功能不停增加。再直接关闭中断,启动的时候发现很快,不需要30分钟。<强>前滚回滚过程 <强>应该是这样的:数据库记录了最新的SCN,增量检查点的SCN,重做日志的最大SCN,通过乃至,这样就完成了前滚,在回滚的时候直接读取
  
  
  
  
  
  如果来自<强>丢失,则也要读取到SGA中的缓冲区缓存中,也就是一次物理读必然产生一个逻
  ,当其他进程读取数据块时,会
  ),就不直接从数据块上读取数据,而
  
  
  <>强了解甲骨文在什么情况下会产生ora - 01555:快照过旧错误
  假设有一6000张万行数据的testdb表,预计testdb全表扫描1次需要2个小时,参考过程如下:
  1,在1点钟,用户一个发出了select * from testdb;此时不管将来testdb怎么变化,正确的结果应该是用户一个会看到在1点钟这个时刻的内容。
  2,在1点30分,用户B执行了更新命令,更新了testdb表中的第4100年万行的这条记录,这时,用户一个的全表扫描还没有到达4100万第条。毫无疑问,这个时候,第4100年万行的这条记录是被写入了回滚段,假设是回滚段UNDOTS1,如果用户一个的全表扫描到达了第4100年万行,是应该会正确的从回滚段UNDOTS1中读取出1点钟时刻的内容的。
  3,这时,用户B将他刚才做的操作提交了,但是这时,系统仍然可以给用户一提供正确的数据,因为那第4100年万行记录的内容仍然还在回滚段UNDOTS1里,系统可以根据SCN到回滚段里找到正确的数据,但要注意到,这时记录在UNDOTS1里的第4100年万行记录已经发生了重大的改变:就是第4100年万行在回滚段UNDOTS1里的数据有可能随时被覆盖掉,因为这条记录已经被提交了!
  4,由于用户一的查询时间漫长,而业务在一直不断的进行,UNDOTS1回滚段在被多个不同的事务使用着,这个回滚段里的程度上循环到了第4100年万行数据所在的程度上,由于这条记录已经被标记提交了,所以这个程度是可以被其他事务覆盖掉的!
  5到1点45分了,用户一的查询终于到了第4100年万行,而这时已经出现了第4条说的情况,需要到回滚段UNDOTS1去找数据,但是已经被覆盖掉了,这时就出现了ora - 01555错误。

提交和dbwr没有任何关系,物理读产生逻辑读,快照过旧的理解