周大師的書中說軟軟解析的核心原理就是通過設置session_cached_cursors參數，將某個會話中常用的SQL放入UGA的會話緩衝區去，當會發發起相同的SQL時，可以快速的從UGA取得CURSOR的信息，從而減少共享池的爭用，當一個CURSOR被解析3次以上（包括3次）時就會被放入到UGA會話緩衝區中。下面是實驗過程：
SQL> select * from v$version where rownum<2;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit
首先查詢出LIBRARY CACHE LATCH的內存地址如下：
SQL> select 'oradebug poke 0x' || addr || ' 1 0x01'
2 from v$latch_children where name='library cache';
'ORADEBUGPOKE0X'||ADDR||'10X01'
---------------------------------------
oradebug poke 0x0000000077947860 1 0x01
測試一：library cache latch對硬解析的影響：
會話1：用oradebug工具手動的持有library cahe lacth
SQL> oradebug setmypid
Statement processed.
SQL> oradebug poke 0x0000000077947860 1 0x01
BEFORE: [077947860, 077947864) = 00000000
AFTER: [077947860, 077947864) = 00000001
會話2：進行硬解析直接掛起,如下：
SQL> select count (*) from dba_ojbects;--直接掛起
------------------------------------------------------------------------------------
測試二：library cache latch對軟解析的影響：
會話1：
先進行硬解析，如下：
SQL> select count(*) from dba_objects;
COUNT(*)
----------
50611
會話2：
用oradebug工具手動的持有library cache lacth
SQL> oradebug setmypid
Statement processed.
SQL> oradebug poke 0x0000000077947860 1 0x01
BEFORE: [077947860, 077947864) = 00000000
AFTER: [077947860, 077947864) = 00000001
會話1：
SQL> select count(*) from dba_objects;
COUNT(*)
----------
50611
SQL> /----仍然掛起
---------------------------------------------------------------------------------------
測試三：library cache latch對軟軟解析的影響：
會話1：
先執行3次解析，那麼第四次就會進行軟軟解析，如下：
SQL> select count(*) from dba_objects;
COUNT(*)
----------
50611
SQL> /
COUNT(*)
----------
50611
SQL> /
COUNT(*)
----------
50611
用oradebug工具手動的持有library cahe lacth
SQL> oradebug setmypid
Statement processed.
SQL> oradebug poke 0x0000000077947860 1 0x01
BEFORE: [077947860, 077947864) = 00000000
AFTER: [077947860, 077947864) = 00000001
會話1：
在進行第4次解析的時候可以繼續執行SQL，並且不在需要library cache latch，從而驗證了文章開頭說的話。
注：oradebug工具的使用：http://blog.csdn.net/tianlesoftware/article/details/6525628