DML 语句处理过程

如果是DML语句：

update tab set col1='A' where col1='B'

第1步: 创建游标(Create a Cursor)

由程序接口调用创建一个游标(cursor)。任何SQL语句都会创建它，特别在运行DML语句时，都是自动创建游标的，不需要开发人员干预。多数应用中，游标的创建是自动的。然而，在预编译程序(pro*c)中游标的创建，可能是隐含的，也可能显式的创建。在存储过程中也是这样的。

第2步:分析语句(Parse the Statement)

这里分为语法和语句解析

首先判断是否在shared pool里相同的SQL；这主要是通过绑定变量(bind variable)实现的，也就是我们常说的共享SQL，---why shared pool

如果有--就直接拿之即用

如果没有

2.1 验证它是合法的语句，即书写正确

　 2.2 实现数据字典的查找，以验证是否符合表和列的定义-----why 有数据字典缓冲区

　 2.3 在所要求的对象上获取语法分析锁，使得在语句的语法分析过程中不改变这些对象的定义

　 2.4 验证为存取所涉及的模式对象所需的权限是否满足----why 有数据字典缓冲区

第3步:执行计划的创建或者获取

第4步:根据执行计划得出col1='B'的记录存放在10号数据文件的54号数据块里。

第5步:判断UNDO是否有此数据快

服务器进程在buffer cache里找一个可用的undo数据块，如果没有发现，则到undo表空间里找一个可用的undo块，并调入buffer cache。假设获得的undo数据块号为24号，位于11号undo数据文件里。

UNDO多版本一致性读和回退

第6步:将改变前的值，也就是A放入11号undo数据块。

第7步:由于undo数据块发生了变化，于是产生重做记录，假设重做记录号为120。

　行号 事务id file# block# row column value

　　120 T1 24 11 10 col1 A

第8步:、在buffer cache里找到54号数据块。如果没有发现，则从10号数据文件里调入

第9步:、将改变后的值，也就是B放入54号数据块（内存）

第10步:由于数据块发生了变化，于是产生重做记录，假设重做记录号为121。

　　行号 事务id file# block# row column value

121 T1 10 54 10 col1 B

第11步：控制权返回给用户，如果在SQL*Plus里执行DML，则表现为光标返回。

第12步：当用户发出commit命令时，触发LGWR进程，将120与121这两个重做记录写入联机日志文件，并将54号数据块和11号undo数据块头部所记录的事务状态标记设置为已提交。然后控制权返回给用户，如果在SQL*Plus里执行DML操作，则表现为光标返回。

第13步：这个时候，54号数据块以及11号undo块并不一定被DBWn写入数据文件。只有在脏数据块的数量达到一定程度才会被写入。

事务只要被提交或回滚，那么该事务所使用的undo块就可以被覆盖。对于上面的例子来说，当第10步，用户发出commit命令以后，11号undo块里的数据就可以被其他事务所覆盖。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/500314/viewspace-1063657/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/500314/viewspace-1063657/