oracle types.cursortype,深入解析Cursor和绑定变量

如下是我就这次演讲的内容做的一点概括，里面也包含了我回答一些朋友的问题的邮件内容：

里的cursor分为两种：一种是shared cursor，一种是session cursor。

所谓的shared cursor就是指缓存在library cache里的一种library cache object，说白了就是指缓存在library cache里的sql和匿名pl/sql。它们是缓存在library cache中的几十种library cache object之一，它所属于的namespace是CRSR(也就是cursor的缩写)。你信里提到的parent cursor和child cursor都是shared cursor，它们都是以library cache object handle的方式存在library cache里，当一条sql第一次被执行的时候，会同时产生parent cursor和child cursor，parent cursor的library cache object handle的heap 0里会存储其child cursor的地址，这个sql的执行计划会存储在上述child cursor的library cache object handle的heap 6中，第一次执行上述sql所产生的parent cursor和child cursor的过程也就是所谓的"硬解析"主要做的事情。如果上述sql再次执行，Oracle只需要去扫描相应的library cache object handle，找到上次硬解析后产生的child cursor，把里面的parse tree和执行计划直接拿过用就可以了，这就是所谓的"软解析"。

Oracle里的第二种cursor就是session cursor，session cursor又分为三种：分别是implicit cursor，explicit cursor和ref cursor。所谓的session cursor其实就是指的跟这个session相对应的server process的PGA里(准确的说是UGA)的一块内存区域(或者说内存结构)，它的目的是为了处理且一次只处理一条sql语句(这里是指一个implicit cursor一次只处理一条sql，explicit cursor和ref cursor处理sql的数量是由你自己所控制)。

一个session cursor只能对应一个shared cursor，而一个shared cursor却可能同时对应多个session cursor。

当某个session cursor和其对应的shared cursor建立关联后，如果你把cursor_space_for_time调成true，当一个session cursor处理完一条sql后，它就不会被destroy，Oracle会把其cache起来(我们称之为soft closed session cursor)，这么做的目的是很明显的，因为这个soft closed掉的session cursor已经和包含其执行计划和parse tree的shared cursor建立了联系，那么当在这个session中再次执行同样的sql的时候，Oracle就不再需要去扫描library cache了，直接把刚才已经soft closed掉的session cursor拿过来用就好了，这就是