当我们发出一条DML,(比如 update t set col1='A' where col1='B') 语句时,
其执行过程大概可以如下概括:
1: 在SGA 内存的share pool 里寻找相同的解析计划,找到就直接重用;如果没有,则生成新的执行计划。(所谓 解析计划简单理解就是针对SQL语句所引用的表进行表数据分布,表数据量以及列上的索引等相关信息的搜集)
2: 假设根据执行计划,得出col1='B' 的记录存放在10号数据文件的54号数据块里。
3: 服务器进程在buffer cache 里找一个可用undo数据块,如果没有发现,则到undo表空间里找一个可用的undo块,并调入buffer cache。(找不到就尝试获取其他undo segment里的 expired 状态的 extends; 如果仍然没有得到,undo表空间里的数据文件启用了自动扩展,则数据文件进行自动扩展;如果不能自动扩展,就尝试使用其它undo segment里的 InActive 状态的extends,如果以上步骤均无法获得可用空间,则报错啦,undo表空间不足!) 假设获得的undo数据块号为24,位于11号undo数据文件里。
4: 将改变前的值,也就是B放入11号undo数据块。
5: 由于undo数据块发生了变化,于是产生重做记录,假设重做记录号为120。
行号 事务id file# block# row colum value
120 T1 24 11 10 col1 B
6: 在buffer cache 时找到54号数据块。 如果没有发现,则从10号数据文件里调入。
7:将改变后的值,也就是A放入54号数据块。
8: 由于数据块发生变化,于是产生重做记录,假设重做记录号为121。
行号 事务id file# block# row colum value
121 T1 10 54 10 col1 A
9: 控制权返回给用户,如果在SQL*Plus里执行DML,则表现为光标返回。
10: 当用户发出commit命令时,触发LGWR进程,将120与121这两个重做记录写入联机日志文件,并将54号
数据块和11号数据块头部所记录的事务状态标记设置为已提交。然后控制权返回给用户,如果在SQL*Plus里执行DML,则表现为光标返回。
11: 这个时候,54号数据块以及11号undo块并不一定被DBWn写入数据文件。只有在脏数据块的数量达到一定程度才会被写入。
注意: 事务只要被提交或回滚,那么事务所使用的undo块数据就可以被覆盖。对于上面的例子来说,当第10步,用户发出commit命令后,11号undo块里的数据就可以被其它事务所覆盖。