这篇文章将为大家详细讲解有关怎么解析Cursor和绑定变量，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。
如下是我就这次演讲的内容做的一点概括，里面也包含了我回答一些朋友的问题的邮件内容：
Oracle里的cursor分为两种：一种是shared cursor，一种是session cursor。
所谓的shared cursor就是指缓存在library cache里的一种library cache object，说白了就是指缓存在library cache里的sql和匿名pl/sql。它们是oracle缓存在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拿过来用就好了，这就是所谓的"软软解析"。
最后我说一下特别容易混淆的Oracle里几个关于cursor的参数的含义：
1、open_cursors
open_cursors指的是在单个session中同时能以open状态存在的session cursor的最大数量
2、session_cached_cursors
session_cached_cursors指的是单个session中同时能cache住的soft closed session cursor的最大数量
3、cursor_space_for_time
关于cursor_space_for_time有三点需要注意：1) 10.2.0.5和11.1.0.7里它已经作废了；2) 把它的值调成true后如果还同时用到了绑定变量，则由于Bug 6696453的关系，可能会导致logical data corruption；3) 把它的值调成true后，所有的child cursor在执行完后依然会持有library cache pin，直到其parent cursor关闭
首先我们来看一下library cache object所属于的namespace的定义：
1. Library cache objects are grouped in namespaces according to their type.
2. Each object can only be of one type.
3. All the objects of the same type are in the same namespace.
4. A namespace may be used by more than one type.
5. The most important namespace is called cursor (CRSR) and houses the shared SQL cursors.
你在obj$看到的关于namespace的解释当然是不全的，因为像shared cursor这样的library cache object根本就不在obj$里。
所以实际上你可以这样理解：namespace是针对缓存在library cache里的library cache object来说的，那为什么obj$里会有namespace的定义呢？----因为library cache object有一部分的来源就是来自于数据库里已经存在的、固化的object的metadata。
我们再来看一下library cache object所属于的namespace的详细说明：
Currently there are 64 different object types but this number may grow at any time with the introduction of new features. Examples of types are: cursor, table, synonym, sequence, index, LOB, Java source, outline, dimension, and so on. Not every type corresponds to a namespace. Actually, there are only 32 namespaces which, of course, are also subject to increase at any time.
What is a certainty is that all the objects of the same type will always be stored in the same namespace. An object can only be of one type, hence the search for an object in the library cache is reduced to a search for this object in the corresponding namespace.
Some namespaces contain objects of two or three different types. These are some of the most commonly used namespaces:
CRSR: Stores library objects of type cursor (shared SQL statements)
TABL/PRCD/TYPE: Stores tables, views, sequences, synonyms, procedure specifications, function specifications, package specifications, libraries, and type specifications
BODY/TYBD: Stores procedure, function, package, and type bodies
TRGR: Stores library objects of type trigger
INDX: Stores library objects of type index
CLST: Stores library objects of type cluster
The exact number and name of namespaces in use depends on the server features that are used by the application. For example, if the application uses Java, namespaces like JVSC (java source) and JVRE (Java resource) may be used, otherwise they will not be used.
Note: These namespaces do not store tables, clusters, or indexes as such, only the metadata is stored.
最后的结论是：我也看不到KQD.H的内容，所以我也无法知道Oracle里所有的namespace的准确namespace id，但是其实你是可以通过library cache dump里的所有namespace的列表来猜出来的，因为这显示是按namespace id来排序的。
可以通过library cache dump知道某个Oracle的版本下所有的namespace，如下所示的是9.2.0.6的：
LIBRARY CACHE STATISTICS:
namespace gets hit ratio pins hit ratio reloads invalids
-------------- --------- --------- --------- --------- ---------- ----------
CRSR 1078 0.860 4989 0.935 17 0
TABL/PRCD/TYPE 596 0.636 780 0.624 0 0
BODY/TYBD 1 0.000 0 0.000 0 0
TRGR 1 0.000 1 0.000 0 0
INDX 76 0.474 45 0.111 0 0
CLST 148 0.953 203 0.961 0 0
OBJE 0 0.000 0 0.000 0 0
PIPE 0 0.000 0 0.000 0 0
LOB 0 0.000 0 0.000 0 0
DIR 0 0.000 0 0.000 0 0
QUEU 30 0.700 30 0.700 0 0
OBJG 0 0.000 0 0.000 0 0
PROP 0 0.000 0 0.000 0 0
JVSC 0 0.000 0 0.000 0 0
JVRE 0 0.000 0 0.000 0 0
ROBJ 0 0.000 0 0.000 0 0
REIP 0 0.000 0 0.000 0 0
CPOB 0 0.000 0 0.000 0 0
EVNT 1 0.000 1 0.000 0 0
SUMM 0 0.000 0 0.000 0 0
DIMN 0 0.000 0 0.000 0 0
CTX 0 0.000 0 0.000 0 0
OUTL 0 0.000 0 0.000 0 0
RULS 0 0.000 0 0.000 0 0
RMGR 0 0.000 0 0.000 0 0
IFSD 1 0.000 0 0.000 0 0
PPLN 0 0.000 0 0.000 0 0
PCLS 0 0.000 0 0.000 0 0
SUBS 0 0.000 0 0.000 0 0
LOCS 0 0.000 0 0.000 0 0
RMOB 0 0.000 0 0.000 0 0
RSMD 0 0.000 0 0.000 0 0
JVSD 0 0.000 0 0.000 0 0
ENPR 0 0.000 0 0.000 0 0
RELC 0 0.000 0 0.000 0 0
STREAM 0 0.000 0 0.000 0 0
APPLY 0 0.000 0 0.000 0 0
APPLY SOURCE 0 0.000 0 0.000 0 0
APPLY DESTN 0 0.000 0 0.000 0 0
TEST 0 0.000 0 0.000 0 0
CUMULATIVE 1932 0.778 6049 0.888 17 0
从结果里看9.2.0.6是一共有40个namespace。
关于怎么解析Cursor和绑定变量就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
