Oracle-DBA技术-CURSOR共享0.docx

OracleDBA应知应会--CURSOR共享CURSOR共享是共享池的重要功能之一,通过CURSOR共享，可以提高共享池的使用效率，减少SQL解析的开销，从总体上提高SQL执行的效率。如果一个SQL能够被解析一次，执行多次，那么就可以达到比较好的效果，减少分析的开销。这是OracleSQL共享的最高目标。要实现CURSOR共享，首先要具备一定的机制，也就是说CURSOR的一些执行结构不能存放在程序的私有空间里，而需要存放在共享内存中。共享池中的LibraryCache就是实现这种共享机制的载体。一个可共享的CURSOR，其可共享的部件是存放在LIBRARYCACHE中的，这样就实现了不同SESSION可以共享同一个SQL。满足了存放在共享内存中的条件后，下一步就是要来判断哪些SQL是可以共享的。最简单的方法就是SQL语句完全相同的SQL是可以共享的，如何来判断SQL完全相同呢？如果对该SQL的语义语法进行全面解析，通过最终分解出的TOKEN来进行比较是最好的，能够对SQL进行全面的识别，但是这种识别方式的开销很大，Oracle采取了一个十分巧妙的方法来分辨不同的SQL。就是通过对SQL的文本进行计算，生成一个HASHVALUE，如果HASHVALUE不同，那么SQL肯定不同，如果HASHVALUE相同，就可能是可以共享的SQL。这种机制的实现十分简单，比较相同的SQL的开销也十分小。不过这种机制带来的问题是对SQL的书写要求较高，对于大小写，空格等有严格的书写要求，否则虽然语法语义完全相同的SQL，Oracle也会认为是不同的SQL。基于上述原理，Oracle判断CURSOR共享的第一个原则是，可共享的CURSOR的SQL文本必须完全相同。一个CURSOR在执行前，首先对CURSOR的文本计算HASHVALUE，通过HASHVALUE在HASHBUCKET上找到相同的CURSOR，如果找到了相同的CURSOR，而且该CURSOR的所有的对象（包括SUBHEAP）都是VALID的，那么这个CURSOR在执行的时候，可以使用共享的SQL。如果某些对象已经被AGEOUT，那么这个CURSOR就需要进行软分析，将丢失的部分补充完整才能执行。如果两条SQL的文本完全相同，是不是就一定能够共享呢？答案是否定的。比如有SCOTT和TIGER这两个SCHEMA，下面都有表的名字叫test.如果在这两个用户下都执行select1fromttwhererownum<2,这两个SQL访问的表是不同的，因此这两个SQL是不应该共享的。Oracle在这种情况下是怎么处理的呢？首先，由于SQL文本完全相同，所以这2个SQL具有相同的SQL_ID和hashvalue，被认为是相同的SQL,在v$sqlarea下可以看到如下的结果：SQL_IDADDRESSSQL_TEXTVERSION_COUNTcpjnybv7021rv1F7059E0select1fromttwhererownum<22我们可以看到这条SQL的versioncount是2，也就是存在两个子CURSOR。接下来我们在v$sql中看到如下结果：SQL_IDADDRESSSQL_TEXTcpjnybv7021rv1F7059E0select1fromttwhererownum<2cpjnybv7021rv1F7059E0select1fromttwhererownum<2可以看出，这2个SQL，被认为是同一个SQL，但是cpjnybv7021rv包含2个子cursor。为什么会产生2个子cursor呢，通过v$sql_shared_cursor可以看到：SQL>selectsql_id,address,child_address,child_number,translation_mismatchfrom2v$sql_shared_cursorwheresql_id='cpjnybv7021rv';SQL_IDADDRESSCHILD_ADCHILD_NUMBERTcpjnybv7021rv1F7059E0231974B80Ncpjnybv7021rv1F7059E0232BC2701Y我们看到，第一个子CURSOR在这个视图中的所有mismatch都是N，第二个SQL由于translation_mismatch而导致不能共享，其原因是在做translation的时候发现相关的OBJECT不同。通过LIBRARYCACHEDUMP看(altersystemsetevents'immediatetracenamelibrary_cachelevel10';)：BUCKET67323:LIBRARYOBJECTHANDLE:handle=1f7059e0mutex=1F705A94(2)name