Focus on Oracle

library cache lock latch和library cache pin latch的持有顺序

Cui Hua — Mon, 14 May 2012 13:39:36 +0000

为了方便阐述，这篇文章里我沿用了如下一些术语：

1、用“library cache lock”代表名为library cache lock的enqueue；

2、用“library cache pin”代表名为library cache pin的enqueue；

3、用“Child library cache”代表名为library cache的子latch；

4、用“Child shared pool”代表名为shared pool的子latch；

5、用“Child library cache lock”代表名为library cache lock的子latch；

6、用“Child library cache pin”代表名为library cache pin的子latch；

需要注意的是：从11gR1开始，Oracle用mutex替换了各种跟library cache相关的latch，所以这篇文章的结论并不适用于11g。

另外，这篇文章的结论是基于10.2.0.1，而从10.2.0.2以后，Oracle会用mutex取代针对cursor的library cache pin，所以从10.2.0.2后，软解析/软软解析的时候不再需要持有Child library cache pin。

在“硬解析和软解析情况下latch持有情况分析”这篇文章里我们曾经提到：

1、在每一个library cache object handle上都存在4个链表，它们分别是lock owners，lock waiters，Pin owners，Pin waiters。所以实际上library cache object handle你可以把它看成是library cache lock和library cache pin所保护的resource。而向lock owners和lock waiters里添加/修改一个library cache lock时是需要先持有Child library cache lock；向Pin owners和Pin waiters里添加/修改一个library cache pin时是需要先持有Child library cache pin。

2、SQL在硬解析的时候，会先去持有Child library cache以扫描library cache object handle链表，接着会释放Child library cache（因为找不到相关的library cache object handle），接下来会再次持有Child library cache（因为要修改library cache object handle链表），然后在不释放Child library cache的情况下进而去持有Child shared pool以分配内存，接着释放Child shared pool（因为已经分配完了），接着再释放Child library cache；然后因为要把相关sql的执行计划load到对应的子cursor的library cache object handle中，所以要以exclusive模式获得library cache pin，所以要先持有Child library cache pin；接着因为要以null模式获得library cache lock，所以要先持有Child library cache lock。（这里我提到了应该是先持有Child library cache pin，然后才持有Child library cache lock，但这是不正确的）

后来有位叫overmars的朋友指出我这个结论跟Oracle的文档里描述的结果不一致，并且持有顺序刚好颠倒过来了。所有的Oracle文档里都是说应该先持有Child library cache lock，再持有Child library cache pin。

其实他提到的文档及相关结论我都知道，但为什么会有上述结论是因为如下两点：

1、当我同时手工持有所有的Child library cache lock和Child library cache pin后，发现hang住的硬解析的session是在等待Child library cache pin，所以从这个测试结果来看，应该是Child library cache pin在前，Child library cache lock在后。

2、我觉得Child library cache lock和Child library cache pin对于cursor而言，持有顺序无所谓，谁先谁后都没有太大关系。因为反正也是要以null模式长时间持有library cache lock。

以上观点我一直认为是正确的，直到overmars给我发过来了他按照我的方法做的测试结果——他也是先手工持有所有的Child library cache lock和Child library cache pin，但发现hang住的硬解析的session是在等待Child library cache lock：

(latch info) wait_event=0 bits=0

Location from where call was made: kgllkal: child: multiinstance: latch

waiting for 6d9479a0 Child library cache lock level=6 child#=1

Location from where latch is held: kgllkdl: child: cleanup: latch

Context saved from call: 0

state=busy, wlstate=free

waiters [orapid (seconds since: put on list, posted, alive check)]:

21 (12, 1336717038, 12)

18 (3, 1336717038, 3)

waiter count=2

gotten 118818 times wait, failed first 0 sleeps 0

gotten 0 times nowait, failed: 0

on wait list for 6d9479a0

当他手工释放Child library cache lock后，发现继续hang住的硬解析的session是在等待Child library cache pin：

(latch info) wait_event=0 bits=0

Location from where call was made: kglpnal: child: alloc space: latch

waiting for 6d947900 Child library cache pin level=6 child#=1

Location from where latch is held: kglpndl: child

Context saved from call: 0

state=busy, wlstate=free

waiters [orapid (seconds since: put on list, posted, alive check)]:

10 (96, 1336717122, 96)

11 (81, 1336717122, 81)

12 (27, 1336717122, 27)

21 (9, 1336717122, 9)

18 (9, 1336717122, 9)

waiter count=5

gotten 226675 times wait, failed first 0 sleeps 0

gotten 0 times nowait, failed: 0

on wait list for 6d947900

这里的结果就和我做的结果完全反过来了，而且他给的trace文件是极有说服力的，从上述trace文件可以看到，分别是kgllkal和kglpnal在等待Child library cache lock和Child library cache pin。

我们再来对比看一下我做的同样的测试的结果：

我也是先手工持有所有的Child library cache lock和Child library cache pin后，发现hang住的硬解析的session是在等待Child library cache pin：

(latch info) wait_event=0 bits=0

Location from where call was made: kglpnal: child: alloc space: latch

Context saved from call: 1

waiting for 3213df50 Child library cache pin level=6 child#=2

Location from where latch is held: kglpndl: child

Context saved from call: 1

state=busy, wlstate=free

waiters [orapid (seconds since: put on list, posted, alive check)]:

16 (12, 1336755992, 12)

waiter count=1

gotten 115107 times wait, failed first 0 sleeps 0

gotten 2 times nowait, failed: 0

on wait list for 3213df50

从上述结果可以看到，现在是kglpnal在等待持有Child library cache pin，直到现在为止，这里还看不出来任何异常，也就是说这里并不能说明我的测试结论就一定是错的。

我们接着往下看：

当我手工释放Child library cache pin后，发现继续hang住的硬解析的session是在等待Child library cache lock：

(latch info) wait_event=0 bits=0

Location from where call was made: kgllkdl: child: cleanup: latch

Context saved from call: 1

waiting for 3213e088 Child library cache lock level=6 child#=2

Location from where latch is held: kgllkdl: child: cleanup: latch

Context saved from call: 1

state=busy, wlstate=free

waiters [orapid (seconds since: put on list, posted, alive check)]:

10 (166, 1336756125, 166)

16 (42, 1336756125, 42)

waiter count=2

gotten 54717 times wait, failed first 0 sleeps 0

gotten 0 times nowait, failed: 0

on wait list for 3213e088

从上述trace文件里我们可以看到，表面上看不出啥问题，hang住的硬解析的session确实是在等待Child library cache lock，但当我们仔细看等待的源头的时候发现现在是kgllkdl: child: cleanup: latch在等待上述Child library cache lock，注意里面有child: cleanup: latch的字眼，意味着现在是在释放Child library cache lock的时候遇到了阻塞。也就是说实际上由于某种原因，我并没有手工hold住Child library cache lock，Oracle已经持有了Child library cache lock了，只是在释放的时候被我之前的poke操作阻塞了。

这个是非常奇怪的！难以解释。但从这里我们已经知道了，我之前的结论是有问题的，很可能就是和所有文档里描述的结论一致——即硬解析的时候是先持有Child library cache lock，再持有Child library cache pin。

接下来，我反复做了大量测试，终于在一次的测试结果里重现了overmars的测试结果。

手工持有所有的Child library cache lock和Child library cache pin后，发现hang住的硬解析的session终于是在等待Child library cache lock了：

Process global information:

process: 33E4E3BC, call: 33F5C0A0, xact: 00000000, curses: 33F310C4, usrses: 33F310C4

—————————————-

SO: 33E4E3BC, type: 2, owner: 00000000, flag: INIT/-/-/0×00

(process) Oracle pid=20, calls cur/top: 33F5C0A0/33F5C0A0, flag: (0) -

int error: 0, call error: 0, sess error: 0, txn error 0

(post info) last post received: 0 0 0

last post received-location: No post

last process to post me: none

last post sent: 0 0 0

last post sent-location: No post

last process posted by me: none

(latch info) wait_event=0 bits=0

Location from where call was made: kgllkal: child: multiinstance: latch

Context saved from call: 1

waiting for 3213e088 Child library cache lock level=6 child#=2

Location from where latch is held: kgllkdl: child: cleanup: latch

Context saved from call: 1

state=busy, wlstate=free

waiters [orapid (seconds since: put on list, posted, alive check)]:

10 (42, 1336997400, 42)

20 (18, 1336997400, 18)

waiter count=2

gotten 63233 times wait, failed first 8 sleeps 8

gotten 0 times nowait, failed: 0

on wait list for 3213e088

Process Group: DEFAULT, pseudo proc: 33E7F368

O/S info: user: SYSTEM, term: Y8908CUIHUA, ospid: 3296

OSD pid info: Windows thread id: 3296, image: ORACLE.EXE (SHAD)

当我手工释放Child library cache lock后，发现继续hang住的硬解析的session终于是在等待Child library cache pin了：

*** 2012-05-14 20:11:41.171

Received ORADEBUG command ‘dump processstate 10′ from process Windows thread id: 1448, image:

===================================================

PROCESS STATE

————-

Process global information:

process: 33E4E3BC, call: 33F5C0A0, xact: 00000000, curses: 33F310C4, usrses: 33F310C4

—————————————-

SO: 33E4E3BC, type: 2, owner: 00000000, flag: INIT/-/-/0×00

(process) Oracle pid=20, calls cur/top: 33F5C0A0/33F5C0A0, flag: (0) -

int error: 0, call error: 0, sess error: 0, txn error 0

(post info) last post received: 0 0 0

last post received-location: No post

last process to post me: none

last post sent: 0 0 0

last post sent-location: No post

last process posted by me: none

(latch info) wait_event=0 bits=0

Location from where call was made: kglpnal: child: alloc space: latch

Context saved from call: 1

waiting for 3213df50 Child library cache pin level=6 child#=2

Location from where latch is held: kglpndl: child

Context saved from call: 1

state=busy, wlstate=free

waiters [orapid (seconds since: put on list, posted, alive check)]:

20 (21, 1336997499, 21)

10 (21, 1336997499, 21)

waiter count=2

gotten 131861 times wait, failed first 9 sleeps 132

gotten 0 times nowait, failed: 0

on wait list for 3213df50

Process Group: DEFAULT, pseudo proc: 33E7F368

O/S info: user: SYSTEM, term: Y8908CUIHUA, ospid: 3296

OSD pid info: Windows thread id: 3296, image: ORACLE.EXE (SHAD)

这里的测试结果就和overmars的结论一致了，且再也没有了上述kgllkdl: child: cleanup: latch。

总结一下：

从上面的分析我们可以看到，实际上所有的文档里描述的结论是对的，这里是我错了。应该是先申请library cache lock，再申请library cache pin，或者说是先持有Child library cache lock，再持有Child library cache pin。

即正确的硬解析的过程为：

SQL在硬解析的时候，会先去持有Child library cache以扫描library cache object handle链表，接着会释放Child library cache（因为找不到相关的library cache object handle），接下来会再次持有Child library cache（因为要修改library cache object handle链表），然后在不释放Child library cache的情况下进而去持有Child shared pool以分配内存，接着释放Child shared pool（因为已经分配完了），接着再释放Child library cache；然后因为要以null模式获得library cache lock，所以要先持有Child library cache lock；接着要把相关sql的执行计划load到对应的子cursor的library cache object handle中，即要以exclusive模式获得library cache pin，所以要先持有Child library cache pin。

软软解析情况下的latch持有情况分析

Cui Hua — Mon, 07 May 2012 15:36:27 +0000

为了方便阐述，这篇文章里我沿用了如下一些术语：

1、用“library cache lock”代表名为library cache lock的enqueue；

2、用“library cache pin”代表名为library cache pin的enqueue；

3、用“Child library cache”代表名为library cache的子latch；

4、用“Child shared pool”代表名为shared pool的子latch；

5、用“Child library cache lock”代表名为library cache lock的子latch；

6、用“Child library cache pin”代表名为library cache pin的子latch；

需要注意的是：从11gR1开始，Oracle用mutex替换了各种跟library cache相关的latch，所以这篇文章的结论并不适用于11g。

另外，这篇文章的结论是基于10.2.0.1，而从10.2.0.2以后，Oracle会用mutex取代针对cursor的library cache pin，所以从10.2.0.2后，软软解析的时候不再需要持有Child library cache pin。

我在“硬解析和软解析情况下latch持有情况分析”这篇文章里对硬解析和软解析情况下的latch持有情况做了分析，得出的结论是：

1、SQL在硬解析的时候，会先去持有Child library cache以扫描library cache object handle链表，接着会释放Child library cache（因为找不到相关的library cache object handle），接下来会再次持有Child library cache（因为要修改library cache object handle链表），然后在不释放Child library cache的情况下进而去持有Child shared pool以分配内存，接着释放Child shared pool（因为已经分配完了），接着再释放Child library cache；然后因为要以null模式获得library cache lock，所以要先持有Child library cache lock；接着要把相关sql的执行计划load到对应的子cursor的library cache object handle中，即要以exclusive模式获得library cache pin，所以要先持有Child library cache pin；

2、SQL在软解析的时候和硬解析类似，只不过不需要持有Child shared pool并且持有Child library cache的时间会更短。

注意这里为什么硬解析/软解析的时候是library cache pin在前，library cache lock在后，我们可以来证明一下（注意这个结论是错误的，实际上应该是library cache lock在前，library cache pin在后）：

这里思路还是和“硬解析和软解析情况下latch持有情况分析”中的一样，即在session 1中手工持有所有的Child library cache lock和所有的Child library cache pin，然后在session 3中观察session 2中latch的等待情况即可确定硬解析/软解析的时候是先持有Child library cache lock还是先持有Child library cache pin。

我们直接来看相关的trace文件：

d:\oracle\admin\cuihua\udump\cuihua_ora_5896.trc的内容：

*** 2012-05-07 22:04:54.843

*** ACTION NAME:(Command Window – New) 2012-05-07 22:04:54.765

*** MODULE NAME:(PL/SQL Developer) 2012-05-07 22:04:54.765

*** SERVICE NAME:(cuihua) 2012-05-07 22:04:54.765

*** SESSION ID:(119.6) 2012-05-07 22:04:54.765

Received ORADEBUG command ‘dump processstate 10′ from process Windows thread id: 6104, image:

===================================================

PROCESS STATE

————-

Process global information:

process: 33E5723C, call: 31AEF434, xact: 00000000, curses: 33F102E4, usrses: 33F102E4

—————————————-

SO: 33E5723C, type: 2, owner: 00000000, flag: INIT/-/-/0×00

(process) Oracle pid=44, calls cur/top: 31AEF434/31AEF434, flag: (0) -

int error: 0, call error: 0, sess error: 0, txn error 0

(post info) last post received: 0 0 0

last post received-location: No post

last process to post me: none

last post sent: 0 0 0

last post sent-location: No post

last process posted by me: none

(latch info) wait_event=0 bits=0

Location from where call was made: kglpnal: child: alloc space: latch

Context saved from call: 1

waiting for 3213df50 Child library cache pin level=6 child#=2

Location from where latch is held: kglpndl: child

Context saved from call: 1

state=busy, wlstate=free

waiters [orapid (seconds since: put on list, posted, alive check)]:

44 (15, 1336399492, 15)

waiter count=1

gotten 220077 times wait, failed first 8 sleeps 2

gotten 0 times nowait, failed: 0

on wait list for 3213df50

Process Group: DEFAULT, pseudo proc: 33E7F368

O/S info: user: SYSTEM, term: Y8908CUIHUA, ospid: 5896

OSD pid info: Windows thread id: 5896, image: ORACLE.EXE (SHAD)

注意上述trace文件中有如下内容：

waiting for 3213df50 Child library cache pin level=6 child#=2

所以session 2在Child library cache lock和Child library cache pin同时被hold住的情况下是会先尝试持有Child library cache pin，即Child library cache pin在前，Child library cache lock在后。――注意这个结论是错误的，我后面专门为此写了一篇文章“library cache lock latch和library cache pin latch的持有顺序”加以纠正。

这里并没有就软软解析和软解析在latch持有情况方面的区别加以说明，我这里补充阐述一下。

先来说一下软解析和软软解析的区别：

我原来一直认为软解析和软软解析没有本质区别（实际上从后面的测试可以看到，它们在跟library cache相关的latch持有情况方面有本质区别，所以软软解析在latch争用方面要比软解析好很多），他们最大的区别就是软解析中的session cursor每次都会重复open/parse/bind/execute/fetch/close的过程，而软软解析中的session cursor只会open/close一次，然后不断重复parse/bind/execute/fetch，省掉的就是重复open/close的时间。

接着我们来说一下有关软解析和软软解析的一个重要知识点：

Note also that a cursor is put in the session cursor cache only if there are more than three parse calls on it; this behaviour avoids random cursors and cursors with literal to dirty the cache.

注意这是MOS上“How to read session cursor cache statistics using oradebug (doc id 283134.1)”里的结论，但我在10.2.0.1中测试却发现并不是这样，应该是Oracle在10g以及后续的版本里对session cache的算法做了改进。

我在10.2.0.1中实际测试后发现：

当session_cached_cursors的值大于0且缓存的session cursor的数量在当前session中的值还没有达到session_cached_cursors的上限的时候，一个sql第一次软解析的时候就会被cache住，下次再在同一个session中再次执行同样的sql的时候就会是软软解析。如果缓存的session cursor的数量在当前session中的值已经达到session_cached_cursors的上限，则Oracle会用LRU算法来管理当前cache住的session cursor链表。

我们来证明一下上述知识点：

SQL*Plus: Release 10.2.0.1.0 – Production on 星期二 5月 8 08:49:01 2012

SQL> conn sys/oracle@cuihua as sysdba;

已连接。

SQL> show parameter session_cache;

NAME TYPE VALUE

———————————— ———– ——————————

session_cached_cursors integer 20

SQL> select sid from v$mystat where rownum<2;

SID

———-

134

SQL> select spid from v$process where addr in (select paddr from v$session where sid=134);

SPID

————

2644

为了避免干扰，我们查询sid=134的session cache相关信息的时候起另起一个新的session，并在新的session中执行查询sid=134的session cache相关信息的sql：

还未执行目标sql时的初始session cache相关信息:

SQL> select a.name,b.value from v$sesstat b, v$statname a where a.statistic#=b.statistic# and a.name in (‘session cursor cache count’,'session cursor cache hits’,'opened cursors current’) and b.sid=134;

NAME VALUE

—————————————————————- ———-

opened cursors current 0

session cursor cache hits 0

session cursor cache count 3

从上述结果里可以看到，sid=134的session的初始session cached cursor的值是3，此时因为sid=134的session还未执行任何sql，所以session cursor cache hits的值当然是0。

在sid=134的session中第一次执行目标sql，这时是硬解析：

SQL> select count(*) from scott.emp;

COUNT(*)

———-

此时的session cache相关信息为:

NAME VALUE

—————————————————————- ———-

opened cursors current 0

session cursor cache hits 0

session cursor cache count 3

从上述结果里可以看到，当执行完一次目标sql后，session cursor cache count的值和session cursor cache hits的值均没有变化。

在sid=134的session中第二次执行目标sql，此时因为是第一次软解析，所以该session cursor就会被cache住:

SQL> select count(*) from scott.emp;

COUNT(*)

———-

此时的session cache相关信息为:

NAME VALUE

—————————————————————- ———-

opened cursors current 0

session cursor cache hits 0

session cursor cache count 4

从上述结果里可以看到，当第一次以软解析方式执行完目标sql后，session cursor cache count的值从3变成了4，也就是说上述目标sql所对应的session cursor已经被缓存了。因为此时刚刚被缓存，所以session cursor cache hits的值依然是0。

在sid=134的session中第三次执行目标sql:

SQL> select count(*) from scott.emp;

COUNT(*)

———-

此时的session cache相关信息为:

NAME VALUE

—————————————————————- ———-

opened cursors current 0

session cursor cache hits 1

session cursor cache count 4

从上述结果里可以看到，因为上述目标sql所对应的session cursor已经被缓存了，再次执行的时候是能够命中缓存的，所以此时session cursor cache hits的值从0变为了1，表示命中一次缓存的session cursor。

现在我们新开一个sid=129的session：

SQL*Plus: Release 10.2.0.1.0 – Production on 星期二 5月 8 11:04:30 2012

SQL> conn sys/oracle@cuihua as sysdba;

已连接。

SQL> show parameter session_cache;

NAME TYPE VALUE

———————————— ———– ——————————

session_cached_cursors integer 20

SQL> select sid from v$mystat where rownum<2;

SID

———-

129

此时该session的session cache相关信息为:

NAME VALUE

—————————————————————- ———-

opened cursors current 0

session cursor cache hits 0

session cursor cache count 4

从上述结果里可以看到，sid=129的session的初始session cached cursor的值由3 变成了4，此时因为sid=129的session还未执行任何sql，所以session cursor cache hits的值当然是0。

在sid=129的session中第一次执行目标sql，因为目标sql已经在sid=134的session中执行过，所以这里虽然是第一次执行，但已经是软解析：

SQL> select count(*) from scott.emp;

COUNT(*)

———-

此时该session的session cache相关信息为:

NAME VALUE

—————————————————————- ———-

opened cursors current 0

session cursor cache hits 0

session cursor cache count 5

从上述结果里可以看到，当在sid=129的session中第一次以软解析方式执行完目标sql后，session cursor cache count的值从4变成了5，也就是说上述目标sql所对应的session cursor已经被缓存了。因为此时刚刚被缓存，所以session cursor cache hits的值依然是0。

在sid=129的session中第二次执行目标sql:

SQL> select count(*) from scott.emp;

COUNT(*)

———-

此时该session的session cache相关信息为:

NAME VALUE

—————————————————————- ———-

opened cursors current 0

session cursor cache hits 1

session cursor cache count 5

好了，基础知识已经说完，我们进入正题。

我们分四步来考察软软解析时跟library cache相关的各种latch的持有情况，这四步考察latch持有情况的思路均为：同时开3个session，session 1持有所有的相关子latch；session 2先重复执行同样的sql，这样可确保随后在session 2中再次执行同样的sql时是软软解析，在session 1持有完所有的相关子latch后再次执行同样的sql；同时我们在session 3中去做session 2的process dump，从session 3的dump文件中即可看到session 2中的latch持有与等待的情况。

第一步：先来证明在10.2.0.1里，软软解析的时候同样会持有Child library cache：

先分别到session 1、session 2、session 3里做一下准备工作：

Session 1:

SQL> select ‘oradebug poke 0x’ || addr || ‘ 4 0×00000001′ from v$latch_children where name=’library cache’;

‘ORADEBUGPOKE0X’||ADDR||’40X00

————————————-

oradebug poke 0x3213DE80 4 0×00000001

oradebug poke 0x3213DE18 4 0×00000001

oradebug poke 0x3213DDB0 4 0×00000001

Session 2:

这里沿用刚才的sid=134，ospid=2644的session。

Session 3:

SQL> oradebug setospid 2644

Oracle pid: 30, Windows thread id: 2644, image: ORACLE.EXE (SHAD)

准备工作已经做完，我们现在去session 1里手工持有上述Child library cache：

Session 1:

SQL> oradebug setmypid

已处理的语句

SQL> oradebug poke 0x3213DE80 4 0×00000001

BEFORE: [3213DE80, 3213DE84) = 00000000

AFTER: [3213DE80, 3213DE84) = 00000001

SQL> oradebug poke 0x3213DE18 4 0x00000001

BEFORE: [3213DE18, 3213DE1C) = 00000000

AFTER: [3213DE18, 3213DE1C) = 00000001

SQL> oradebug poke 0x3213DDB0 4 0x00000001

BEFORE: [3213DDB0, 3213DDB4) = 00000000

AFTER: [3213DDB0, 3213DDB4) = 00000001

然后到session 2中去执行上述目标查询sql，从结果里可以看到，在软软解析的情况下session 2还是hang住了：

Session 2：

SQL> select count(*) from scott.emp;

……这里hang住了

接着我们到session 3中去对session 2做一下process dump：

Session 3:

SQL> oradebug dump processstate 10

已处理的语句

SQL> oradebug tracefile_name

d:\oracle\admin\cuihua\udump\cuihua_ora_2644.trc

d:\oracle\admin\cuihua\udump\cuihua_ora_2644.trc的内容：

*** 2012-05-08 10:13:33.968

*** SERVICE NAME:(cuihua) 2012-05-08 10:13:33.890

*** SESSION ID:(134.24) 2012-05-08 10:13:33.890

Received ORADEBUG command 'dump processstate 10' from process Windows thread id: 4528, image:

===================================================

PROCESS STATE

-------------

Process global information:

process: 33E51F1C, call: 317B0FFC, xact: 00000000, curses: 33F21C9C, usrses: 33F21C9C

----------------------------------------

SO: 33E51F1C, type: 2, owner: 00000000, flag: INIT/-/-/0x00

(process) Oracle pid=30, calls cur/top: 317B0FFC/317B0FFC, flag: (0) -

int error: 0, call error: 0, sess error: 0, txn error 0

(post info) last post received: 0 0 0

last post received-location: No post

last process to post me: none

last post sent: 0 0 0

last post sent-location: No post

last process posted by me: none

(latch info) wait_event=0 bits=0

Location from where call was made: kglpin: child: heap processing: latch

waiting for 3213ddb0 Child library cache level=5 child#=3

Location from where latch is held: kglpndl: child: before processing: latch

Context saved from call: 0

state=busy, wlstate=free

waiters [orapid (seconds since: put on list, posted, alive check)]:

10 (126, 1336443212, 126)

31 (108, 1336443212, 108)

15 (105, 1336443212, 105)

11 (99, 1336443212, 99)

30 (84, 1336443212, 84)

24 (66, 1336443212, 66)

23 (66, 1336443212, 66)

21 (63, 1336443212, 63)

22 (63, 1336443212, 63)

waiter count=9

gotten 99309 times wait, failed first 53 sleeps 2

gotten 294 times nowait, failed: 0

on wait list for 3213ddb0

Process Group: DEFAULT, pseudo proc: 33E7F368

O/S info: user: SYSTEM, term: Y8908CUIHUA, ospid: 2644

OSD pid info: Windows thread id: 2644, image: ORACLE.EXE (SHAD)

……省略显示其他内容

注意上述trace文件中有如下内容：

waiting for 3213ddb0 Child library cache level=5 child#=3

所以我们已经证明了软软解析同样会持有Child library cache，即过度的软软解析同样会导致Child library cache的争用。

手工释放上述Child library cache后session 2恢复正常：

SQL> select count(*) from scott.emp;

COUNT(*)

———-

从下述结果里可以看到现在session cursor cache hits的值由1变成了2，所以刚才执行的目标sql毫无疑问是软软解析：

NAME VALUE

—————————————————————- ———-

opened cursors current 0

session cursor cache hits 2

session cursor cache count 4

第二步：我们来证明软软解析的时候不需要持有Child library cache lock，这一点跟软解析有本质区别：

先分别到session 1、session 2、session 3里做一下准备工作：

Session 1:

SQL> select ‘oradebug poke 0x’ || addr || ‘ 4 0×00000001′ from v$latch_children where name=’library cache lock’;

‘ORADEBUGPOKE0X’||ADDR||’40X00

————————————-

oradebug poke 0x3213E0F0 4 0×00000001

oradebug poke 0x3213E088 4 0×00000001

oradebug poke 0x3213E020 4 0×00000001

Session 2:

这里沿用刚才的sid=134，ospid=2644的session。

Session 3:

SQL> oradebug setospid 2644

Oracle pid: 30, Windows thread id: 2644, image: ORACLE.EXE (SHAD)

准备工作已经做完，我们现在去session 1里手工持有上述Child library cache lock：

Session 1:

SQL> oradebug setmypid

已处理的语句

SQL> oradebug poke 0x3213E0F0 4 0×00000001

BEFORE: [3213E0F0, 3213E0F4) = 00000000

AFTER: [3213E0F0, 3213E0F4) = 00000001

SQL> oradebug poke 0x3213E088 4 0x00000001

BEFORE: [3213E088, 3213E08C) = 00000000

AFTER: [3213E088, 3213E08C) = 00000001

SQL> oradebug poke 0x3213E020 4 0x00000001

BEFORE: [3213E020, 3213E024) = 00000000

AFTER: [3213E020, 3213E024) = 00000001

然后到session 2中去执行上述目标查询sql，从结果里可以看到，在软软解析的情况下session 2没有hang住：

Session 2：

SQL> select count(*) from scott.emp;

COUNT(*)

----------

手工释放上述Child library cache lock，注意这一步是一定要做的，否则如下的查询sid=134的session cache情况的sql就会hang住。

从下述结果里可以看到现在session cursor cache hits的值由2变成了3，所以刚才执行的目标sql毫无疑问是软软解析：

SQL> select a.name,b.value from v$sesstat b, v$statname a where a.statistic#=b.statistic# and a.name in ('session cursor cache count','session cursor cache hits','opened cursors current') and b.sid=134;

NAME VALUE

---------------------------------------------------------------- ----------

opened cursors current 0

session cursor cache hits 3

session cursor cache count 4

第三步：同理可证在10.2.0.1里，软软解析同样会持有Child library cache pin，我们直接来看相关的trace文件：

d:\oracle\admin\cuihua\udump\cuihua_ora_4276.trc的内容：

PROCESS STATE

-------------

Process global information:

process: 33E4FB7C, call: 33F5FA78, xact: 00000000, curses: 33F21C9C, usrses: 33F21C9C

----------------------------------------

SO: 33E4FB7C, type: 2, owner: 00000000, flag: INIT/-/-/0x00

(process) Oracle pid=24, calls cur/top: 33F5FA78/33F5FA78, flag: (0) -

int error: 0, call error: 0, sess error: 0, txn error 0

(post info) last post received: 0 0 0

last post received-location: No post

last process to post me: none

last post sent: 0 0 0

last post sent-location: No post

last process posted by me: none

(latch info) wait_event=0 bits=0

Location from where call was made: kglpnal: child: alloc space: latch

waiting for 3213dee8 Child library cache pin level=6 child#=3

Location from where latch is held: kglpndl: child

Context saved from call: 0

state=busy, wlstate=free

waiters [orapid (seconds since: put on list, posted, alive check)]:

10 (24, 1336447380, 24)

24 (15, 1336447380, 15)

11 (12, 1336447380, 12)

waiter count=3

gotten 74165 times wait, failed first 5 sleeps 2

gotten 0 times nowait, failed: 0

on wait list for 3213dee8

Process Group: DEFAULT, pseudo proc: 33E7F368

O/S info: user: SYSTEM, term: Y8908CUIHUA, ospid: 2300

OSD pid info: Windows thread id: 2300, image: ORACLE.EXE (SHAD)

Dump of memory from 0x33E3AE04 to 0x33E3AF88

……省略显示其他内容

注意上述trace文件中有如下内容：

waiting for 3213dee8 Child library cache pin level=6 child#=3

所以我们已经证明了在10.2.0.1里，软软解析同样会持有Child library cache pin。

手工释放上述Child library cache pin后session 2恢复正常：

SQL> select count(*) from scott.emp;

COUNT(*)

———-

从下述结果里可以看到现在session cursor cache hits的值由3变成了4，所以刚才执行的目标sql毫无疑问是软软解析：

NAME VALUE

—————————————————————- ———-

opened cursors current 0

session cursor cache hits 4

session cursor cache count 4

第四步：我们证明了10.2.0.5里软软解析的时候是真的不再需要持有Child library cache pin了，这个是因为从10.2.0.2以后，Oracle会用mutex取代针对cursor的library cache pin，即软解析/软软解析的时候不再需要以share模式申请library cache pin，所以保护library cache pin的Child library cache pin当然就不再需要持有了:

还是先分别到session 1、session 2、session 3中做一下准备工作：

Session 1:

SQL> select ‘oradebug poke 0x’ || addr || ‘ 4 0×00000001′ from v$latch_children where name=’library cache pin’;

‘ORADEBUGPOKE0X’||ADDR||’40X00

———————————————

oradebug poke 0x07000000BAC73100 4 0×00000001

oradebug poke 0x07000000BAC73060 4 0×00000001

oradebug poke 0x07000000BAC72FC0 4 0×00000001

Session 2:

SQL> select * from v$version;

BANNER

—————————————————————-

Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 – 64bi

PL/SQL Release 10.2.0.5.0 – Production

CORE 10.2.0.5.0 Production

TNS for IBM/AIX RISC System/6000: Version 10.2.0.5.0 – Productio

NLSRTL Version 10.2.0.5.0 – Production

SQL> select sid from v$mystat where rownum=1;

SID

———-

415

SQL> select spid from v$process where addr in (select paddr from v$session where sid=415);

SPID

————

1052802

SQL> show parameter session_cache;

NAME TYPE VALUE

———————————— ———– ——————————

session_cached_cursors integer 20

SQL> select count(*) from scott.emp;

COUNT(*)

———-

另外在一个新的session中观察sid=415的session cache情况：

NAME VALUE

—————————————————————- ———-

opened cursors current 0

session cursor cache hits 45

session cursor cache count 20

反复多次执行，直到确保session cursor cache hits的值增加，即确保此后再次执行的时候会是软软解析：

SQL> select count(*) from scott.emp;

COUNT(*)

———-

SQL> select count(*) from scott.emp;

COUNT(*)

———-

SQL> select count(*) from scott.emp;

COUNT(*)

———-

重复执行完上述sql后观察sid=415的session cache情况：

NAME VALUE

—————————————————————- ———-

opened cursors current 0

session cursor cache hits 46

session cursor cache count 20

可以看到现在session cursor cache hits的值由45变成了46，即后续在该session cursor没有被age out出缓存的session cursor链表之前，始终能确保再次执行同样的sql会是软软解析。

Session 3:

SQL> oradebug setospid 1052802

Oracle pid: 65, Unix process pid: 1052802, image: oracle@p690ca

准备工作已经做完了，我们现在开始到session 1中持有所有的Child library cache pin：

Session 1：

SQL> oradebug setmypid

Statement processed.

SQL> oradebug poke 0x07000000BAC73100 4 0×00000001

oradebug poke 0x07000000BAC73060 4 0×00000001

BEFORE: [7000000BAC73100, 7000000BAC73104) = 00000000

AFTER: [7000000BAC73100, 7000000BAC73104) = 00000001

SQL> BEFORE: [7000000BAC73060, 7000000BAC73064) = 00000000

AFTER: [7000000BAC73060, 7000000BAC73064) = 00000001

SQL> oradebug poke 0x07000000BAC72FC0 4 0x00000001

BEFORE: [7000000BAC72FC0, 7000000BAC72FC4) = 00000000

AFTER: [7000000BAC72FC0, 7000000BAC72FC4) = 00000001

然后到session 2中去执行上述目标查询sql，从结果里可以看到，在软软解析的情况下session 2没有hang住：

Session 2：

SQL> select count(*) from scott.emp;

COUNT(*)

----------

手工释放上述Child library cache pin，注意这一步是一定要做的，否则如下的查询sid=415的session cache情况的sql就会hang住。

从下述结果里可以看到现在session cursor cache hits的值由46变成了47，所以刚才执行的目标sql毫无疑问是软软解析：

NAME VALUE

---------------------------------------------------------------- ----------

opened cursors current 0

session cursor cache hits 47

session cursor cache count 20

同理可证在10.2.0.5里，软软解析的时候不再需要持有Child library cache，但需要持有Child library cache lock。

如下是在10.2.0.5里软软解析且产生Child library cache lock等待时Session 2的trace文件：

/u01/app/oracle/admin/ipratest/udump/ipratest_ora_1049072.trc

Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

ORACLE_HOME = /u01/app/oracle/product/10.2.0

System name: AIX

Node name: p690ca

Release:3

Version: 5

Machine:003716BA4C00

Instance name: ipratest

Redo thread mounted by this instance: 1

Oracle process number: 46

Unix process pid: 1049072, image: oracle@p690ca

*** 2012-05-08 15:24:22.293

*** ACTION NAME:() 2012-05-08 15:24:22.292

*** MODULE NAME:(SQL*Plus) 2012-05-08 15:24:22.292

*** SERVICE NAME:(ipratest) 2012-05-08 15:24:22.292

*** SESSION ID:(385.4145) 2012-05-08 15:24:22.292

Received ORADEBUG command 'dump processstate 10' from process Unix process pid: 1130822, image:

===================================================

PROCESS STATE

-------------

Process global information:

process: 7000000be5b48e0, call: 7000000b87859b0, xact: 0, curses: 7000000be872968, usrses: 7000000be872968

----------------------------------------

SO: 7000000be5b48e0, type: 2, owner: 0, flag: INIT/-/-/0x00

(process) Oracle pid=46, calls cur/top: 7000000b87859b0/7000000b87859b0, flag: (0) -

int error: 0, call error: 0, sess error: 0, txn error 0

(post info) last post received: 0 0 0

last post received-location: No post

last process to post me: none

last post sent: 0 0 0

last post sent-location: No post

last process posted by me: none

(latch info) wait_event=0 bits=0

waiting for 7000000bac731a0 Child library cache lock level=6 child#=3

Location from where latch is held: kgllkdl: child: cleanup: latch

Context saved from call: 0

state=busy, wlstate=free

waiters [orapid (seconds since: put on list, posted, alive check)]:

21 (15, 1336461862, 3)

11 (15, 1336461862, 3)

46 (12, 1336461862, 3)

63 (9, 1336461862, 3)

61 (6, 1336461862, 3)

71 (3, 1336461862, 3)

waiter count=6

gotten 3414877 times wait, failed first 288 sleeps 489

gotten 0 times nowait, failed: 0

on wait list for 7000000bac731a0

Process Group: DEFAULT, pseudo proc: 7000000be666078

O/S info: user: oracle, term: UNKNOWN, ospid: 1049072

OSD pid info: Unix process pid: 1049072, image: oracle@p690ca

—————————————-

SO: 7000000be872968, type: 4, owner: 7000000be5b48e0, flag: INIT/-/-/0×00

(session) sid: 385 trans: 0, creator: 7000000be5b48e0, flag: (41) USR/- BSY/-/-/-/-/-

DID: 0001-002E-0000001E, short-term DID: 0000-0000-00000000

txn branch: 0

oct: 3, prv: 0, sql: 7000000bd1a5760, psql: 70000009ac4aef0, user: 55/CAIPRA

service name: ipratest

O/S info: user: cuihua, term: Y8908CUIHUA, ospid: 5288:3496, machine: WORKGROUP\Y8908CUIHUA

program: sqlplusw.exe

application name: SQL*Plus, hash value=3669949024

waiting for ‘latch: library cache lock’ wait_time=0, seconds since wait started=9

address=7000000bac731a0, number=da, tries=1e

blocking sess=0×0 seq=91

Dumping Session Wait History

for ‘latch: library cache lock’ count=1 wait_time=0.292988 sec

address=7000000bac731a0, number=da, tries=1d

for ‘latch: library cache lock’ count=1 wait_time=0.292987 sec

address=7000000bac731a0, number=da, tries=1c

for ‘latch: library cache lock’ count=1 wait_time=0.293009 sec

address=7000000bac731a0, number=da, tries=1b

for ‘latch: library cache lock’ count=1 wait_time=0.292986 sec

address=7000000bac731a0, number=da, tries=1a

for ‘latch: library cache lock’ count=1 wait_time=0.292993 sec

address=7000000bac731a0, number=da, tries=19

for ‘latch: library cache lock’ count=1 wait_time=0.292987 sec

address=7000000bac731a0, number=da, tries=18

for ‘latch: library cache lock’ count=1 wait_time=0.292986 sec

address=7000000bac731a0, number=da, tries=17

for ‘latch: library cache lock’ count=1 wait_time=0.292987 sec

address=7000000bac731a0, number=da, tries=16

for ‘latch: library cache lock’ count=1 wait_time=0.292988 sec

address=7000000bac731a0, number=da, tries=15

for ‘latch: library cache lock’ count=1 wait_time=0.292987 sec

address=7000000bac731a0, number=da, tries=14

Sampled Session History of session 385 serial 4145

—————————————————

The sampled session history is constructed by sampling

the target session every 1 second. The sampling process

captures at each sample if the session is in a non-idle wait,

an idle wait, or not in a wait. If the session is in a

non-idle wait then one interval is shown for all the samples

the session was in the same non-idle wait. If the

session is in an idle wait or not in a wait for

consecutive samples then one interval is shown for all

the consecutive samples. Though we display these consecutive

samples in a single interval the session may NOT be continuously

idle or not in a wait (the sampling process does not know).

The history is displayed in reverse chronological order.

……省略显示其他内容

最后，我们总结一下（注意这里只是大致的描述，并不包含所有的情况）：

1、SQL在软解析的时候，会先去持有Child library cache以扫描library cache object handle链表，接着会释放Child library cache（因为已经找到了目标library cache object handle），然后因为要以null模式获得library cache lock，所以要先持有Child library cache lock；接着因为要准备执行相关sql的执行计划，所以要以share模式获得library cache pin，进而要先持有Child library cache pin；

2、SQL在软软解析的时候，Oracle不同的版本表现不一样（我只测了如下两个版本）：

在10.2.0.1里：软软解析的时候需要持有Child library cache和Child library cache pin，不需要持有Child library cache lock；

在10.2.0.5里：软软解析的时候需要持有Child library cache lock，不需要持有Child library cache和Child library cache pin；

总的来说，软软解析在latch争用方面要比软解析好很多。

硬解析和软解析情况下latch持有情况分析

Cui Hua — Sat, 05 May 2012 05:21:34 +0000

为了方便阐述，这篇文章里我用了如下一些术语：

1、用“library cache lock”代表名为library cache lock的enqueue；

2、用“library cache pin”代表名为library cache pin的enqueue；

3、用“Child library cache”代表名为library cache的子latch；

4、用“Child shared pool”代表名为shared pool的子latch；

5、用“Child library cache lock”代表名为library cache lock的子latch；

6、用“Child library cache pin”代表名为library cache pin的子latch；

你可能需要先阅读如下的三篇文章才能看懂我在说什么：

shared pool latch和library cache latch

library cache lock和library cache pin到底是什么

library cache lock和library cache pin到底是什么（续）

另外需要注意的是：从11gR1开始，Oracle用mutex替换了各种跟library cache相关的latch，所以这篇文章的结论并不适用于11g。

我们首先来看library cache的经典架构：

其中我们可以看到在每一个library cache object handle上都存在4个链表，它们分别是lock owners，lock waiters，Pin owners，Pin waiters。所以实际上library cache object handle你可以把它看成是library cache lock和library cache pin所保护的resource。而向lock owners和lock waiters里添加/修改一个library cache lock时是需要先持有Child library cache lock；向Pin owners和Pin waiters里添加/修改一个library cache pin时是需要先持有Child library cache pin。

无论是硬解析还是软解析，在扫描/修改library cache object handle链表的时候是需要先持有Child library cache；另外，硬解析还涉及到要在shared pool里分配内存，所以硬解析还会持有Child shared pool。

好了，我们来分6步进一步细化和扩展上述结论，这6步考察latch持有情况的思路均为：同时开3个session，session 1中先持有所有的相关子latch；session 2在session 1持有完所有的相关子latch后去执行硬解析/软解析，这个时候session 2一定会hang住；同时我们在session 3中去做session 2的process dump，从session 3的dump文件中即可看到session 2中的latch持有与等待的情况。

好了，我们开始。

第一步：先来证明硬解析会在持有Child library cache且并不释放的情况下转而去持有Child shared pool：

先分别到session 1、session 2、session 3里做一下准备工作：

Session 1:

SQL> select name,value from all_parameters where name=’_kghdsidx_count’;

NAME VALUE

——————————————– —————————————————————-

_kghdsidx_count 1

SQL> select name,level#,child#,addr,gets from v$latch_children where name like ‘library cache%’ or name=’shared pool’;

NAME LEVEL# CHILD# ADDR GETS

————————————————– ———- ———- ——– ———-

shared pool 7 1 04E5D308 783011

shared pool 7 2 04E5D370 26

shared pool 7 3 04E5D3D8 26

shared pool 7 4 04E5D440 26

shared pool 7 5 04E5D4A8 26

shared pool 7 6 04E5D510 26

shared pool 7 7 04E5D578 26

library cache 5 1 3213DE80 406403

library cache 5 2 3213DE18 322236

library cache 5 3 3213DDB0 96778

library cache lock 6 1 3213E0F0 107337

library cache lock 6 2 3213E088 86643

library cache lock 6 3 3213E020 28278

library cache pin 6 1 3213DFB8 204881

library cache pin 6 2 3213DF50 170659

library cache pin 6 3 3213DEE8 51722

library cache pin allocation 3 1 3213E228 561

library cache pin allocation 3 2 3213E1C0 38

library cache pin allocation 3 3 3213E158 206

library cache lock allocation 3 1 3213E360 722

library cache lock allocation 3 2 3213E2F8 46

library cache lock allocation 3 3 3213E290 229

library cache hash chains 9 1 3213E498 0

library cache hash chains 9 2 3213E430 0

library cache hash chains 9 3 3213E3C8 0

25 rows selected

从上述结果可以看到，Child library cache的level为5，Child library cache lock和Child library cache pin的level为6，Child shared pool的level为7，所以已经具备了在不释放Child library cache的情况下进而去持有Child shared pool的条件。

SQL> select ‘oradebug poke 0x’ || addr || ‘ 4 0×00000001′ from v$latch_children where name=’shared pool’ and child#=1;

‘ORADEBUGPOKE0X’||ADDR||’40X00

————————————-

oradebug poke 0x04E5D308 4 0×00000001

因为要测硬解析，这里我flush一下shared pool：

SQL> alter system flush shared_pool;

系统已更改。

Session 2:

SQL> select sid from v$mystat where rownum=1;

SID

———-

137

SQL> select spid from v$process where addr in (select paddr from v$session where sid=138);

SPID

————

3952

Session 3:

SQL> oradebug setospid 3952

Oracle pid: 24, Windows thread id: 3952, image: ORACLE.EXE (SHAD)

准备工作已经做完，我们现在去session 1里手工持有上述Child shared pool：

Session 1:

SQL> oradebug setmypid

已处理的语句

SQL> oradebug poke 0x04E5D308 4 0×00000001

BEFORE: [4E5D308, 4E5D30C) = 00000000

AFTER: [4E5D308, 4E5D30C) = 00000001

然后到session 2中去随便执行一条sql，因为刚才在session 1里面flush了shared pool，所以这里一定是硬解析，并且这里一定会hang住：

Session 2：

SQL> select * from scott.emp;

……这里hang住了

接着我们到session 3中去对session 2做一下process dump：

Session 3:

SQL> oradebug dump processstate 10

已处理的语句

SQL> oradebug tracefile_name

d:\oracle\admin\cuihua\udump\cuihua_ora_3952.trc

d:\oracle\admin\cuihua\udump\cuihua_ora_3952.trc的内容：

Dump file d:\oracle\admin\cuihua\udump\cuihua_ora_3952.trc

Sat May 05 01:13:57 2012

ORACLE V10.2.0.1.0 - Production vsnsta=0

vsnsql=14 vsnxtr=3

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production

With the Partitioning, OLAP and Data Mining options

Windows XP Version V5.1 Service Pack 2

CPU : 2 - type 586

Process Affinity : 0x00000000

Memory (Avail/Total): Ph:1005M/2030M, Ph+PgF:2333M/3921M, VA:1273M/2047M

Instance name: cuihua

Redo thread mounted by this instance: 1

Oracle process number: 24

Windows thread id: 3952, image: ORACLE.EXE (SHAD)

*** 2012-05-05 01:13:57.468

*** ACTION NAME:(Command Window - New) 2012-05-05 01:13:57.406

*** MODULE NAME:(PL/SQL Developer) 2012-05-05 01:13:57.406

*** SERVICE NAME:(cuihua) 2012-05-05 01:13:57.406

*** SESSION ID:(137.75) 2012-05-05 01:13:57.406

Received ORADEBUG command 'dump processstate 10' from process Windows thread id: 2924, image:

===================================================

PROCESS STATE

-------------

Process global information:

process: 33E4FB7C, call: 33F606A8, xact: 00000000, curses: 33F254F4, usrses: 33F254F4

----------------------------------------

SO: 33E4FB7C, type: 2, owner: 00000000, flag: INIT/-/-/0x00

(process) Oracle pid=24, calls cur/top: 33F606A8/33F606A8, flag: (0) -

int error: 0, call error: 0, sess error: 0, txn error 0

(post info) last post received: 0 0 0

last post received-location: No post

last process to post me: none

last post sent: 0 0 0

last post sent-location: No post

last process posted by me: none

(latch info) wait_event=0 bits=20

Location from where call was made: kghupr1: Chunk Header

Context saved from call: 815704132

waiting for 4e5d308 Child shared pool level=7 child#=1

Location from where latch is held: kghupr1: Chunk Header

Context saved from call: 737738784

state=busy, wlstate=free

waiters [orapid (seconds since: put on list, posted, alive check)]:

10 (33, 1336151634, 33)

20 (33, 1336151634, 33)

24 (15, 1336151634, 15)

waiter count=3

gotten 857154 times wait, failed first 316 sleeps 24

gotten 0 times nowait, failed: 0

on wait list for 4e5d308

holding (efd=5) 3213de18 Child library cache level=5 child#=2

Location from where latch is held: kglpndl: child: before processing: latch

Context saved from call: 1

state=busy, wlstate=free

Process Group: DEFAULT, pseudo proc: 33E7F368

O/S info: user: SYSTEM, term: Y8908CUIHUA, ospid: 3952

OSD pid info: Windows thread id: 3952, image: ORACLE.EXE (SHAD)

……省略显示其他内容

注意上述trace文件中有如下内容：

waiting for 4e5d308 Child shared pool level=7 child#=1

holding (efd=5) 3213de18 Child library cache level=5 child#=2

所以我们已经证明了硬解析会在持有Child library cache且并不释放的情况下转而去持有Child shared pool。

第二步：我们来证明硬解析会去持有Child library cache lock，但是是在释放了Child library cache的情况下，也就是说硬解析的时候不会同时持有Child library cache和Child library cache lock：

先在session 1里手工持有所有的Child library cache lock：

Session 1:

SQL> alter system flush shared_pool;

系统已更改。

SQL> select ‘oradebug poke 0x’ || addr || ‘ 4 0×00000001′ from v$latch_children where name=’library cache lock’;

‘ORADEBUGPOKE0X’||ADDR||’40X00

————————————-

oradebug poke 0x3213E0F0 4 0×00000001

oradebug poke 0x3213E088 4 0×00000001

oradebug poke 0x3213E020 4 0×00000001

SQL> oradebug poke 0x3213E0F0 4 0×00000001

BEFORE: [3213E0F0, 3213E0F4) = 00000000

AFTER: [3213E0F0, 3213E0F4) = 00000001

SQL> oradebug poke 0x3213E088 4 0x00000001

BEFORE: [3213E088, 3213E08C) = 00000000

AFTER: [3213E088, 3213E08C) = 00000001

SQL> oradebug poke 0x3213E020 4 0x00000001

BEFORE: [3213E020, 3213E024) = 00000000

AFTER: [3213E020, 3213E024) = 00000001

然后到session 2中去随便执行一条sql，因为刚才在session 1里面flush了shared pool，所以这里一定是硬解析，并且这里一定会hang住：

Session 2:

SQL> select * from scott.emp;

……这里hang住了

接着我们到session 3中去对session 2做一下process dump：

Session 3:

SQL> oradebug dump processstate 10

已处理的语句

SQL> oradebug tracefile_name

d:\oracle\admin\cuihua\udump\cuihua_ora_3140.trc

d:\oracle\admin\cuihua\udump\cuihua_ora_3140.trc的内容：

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production

With the Partitioning, OLAP and Data Mining options

Windows XP Version V5.1 Service Pack 2

CPU : 2 - type 586

Process Affinity : 0x00000000

Memory (Avail/Total): Ph:1142M/2030M, Ph+PgF:2355M/3921M, VA:1345M/2047M

Instance name: cuihua

Redo thread mounted by this instance: 0

Oracle process number: 0

Windows thread id: 3140, image: ORACLE.EXE (SHAD)

KCCDEBUG_LEVEL = 0

Dynamic strand is set to TRUE

Running with 2 shared and 18 private strand(s). Zero-copy redo is FALSE

Dump file d:\oracle\admin\cuihua\udump\cuihua_ora_3140.trc

Sat May 05 01:26:29 2012

ORACLE V10.2.0.1.0 - Production vsnsta=0

vsnsql=14 vsnxtr=3

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production

With the Partitioning, OLAP and Data Mining options

Windows XP Version V5.1 Service Pack 2

CPU : 2 - type 586

Process Affinity : 0x00000000

Memory (Avail/Total): Ph:969M/2030M, Ph+PgF:2332M/3921M, VA:1267M/2047M

Instance name: cuihua

Redo thread mounted by this instance: 1

Oracle process number: 31

Windows thread id: 3140, image: ORACLE.EXE (SHAD)

*** 2012-05-05 01:26:29.609

*** ACTION NAME:(Command Window - New) 2012-05-05 01:26:29.562

*** MODULE NAME:(PL/SQL Developer) 2012-05-05 01:26:29.562

*** SERVICE NAME:(cuihua) 2012-05-05 01:26:29.562

*** SESSION ID:(153.27) 2012-05-05 01:26:29.562

Received ORADEBUG command 'dump processstate 10' from process Windows thread id: 2844, image:

===================================================

PROCESS STATE

-------------

Process global information:

process: 33E5250C, call: 31A8ACBC, xact: 00000000, curses: 33F38174, usrses: 33F38174

----------------------------------------

SO: 33E5250C, type: 2, owner: 00000000, flag: INIT/-/-/0x00

(process) Oracle pid=31, calls cur/top: 31A8ACBC/31A8ACBC, flag: (0) -

int error: 0, call error: 0, sess error: 0, txn error 0

(post info) last post received: 0 0 0

last post received-location: No post

last process to post me: none

last post sent: 0 0 0

last post sent-location: No post

last process posted by me: none

(latch info) wait_event=0 bits=0

Location from where call was made: kgllkdl: child: cleanup: latch

Context saved from call: 1

waiting for 3213e088 Child library cache lock level=6 child#=2

Location from where latch is held: kgllkdl: child: cleanup: latch

Context saved from call: 1

state=busy, wlstate=free

waiters [orapid (seconds since: put on list, posted, alive check)]:

10 (15, 1336152387, 15)

31 (3, 1336152387, 3)

waiter count=2

gotten 135516 times wait, failed first 6 sleeps 5

gotten 0 times nowait, failed: 0

on wait list for 3213e088

Process Group: DEFAULT, pseudo proc: 33E7F368

O/S info: user: SYSTEM, term: Y8908CUIHUA, ospid: 3140

OSD pid info: Windows thread id: 3140, image: ORACLE.EXE (SHAD)

……省略显示其他内容

注意上述trace文件中有如下内容：

waiting for 3213e088 Child library cache lock level=6 child#=2

但注意这里没有holding Child library cache！所以我们已经证明了硬解析会持有Child library cache lock，但是是在释放了Child library cache的情况下，也就是说硬解析的时候不会同时持有Child library cache和Child library cache lock。

第三步：我们来证明硬解析会去持有Child library cache pin，但是是在释放了Child library cache的情况下，也就是说硬解析的时候不会同时持有Child library cache和Child library cache pin：

证明步骤和思路与第二步一模一样，这里不再赘述，我们直接来看相关的process dump的trace文件：

d:\oracle\admin\cuihua\udump\cuihua_ora_2444.trc的内容：

Dump file d:\oracle\admin\cuihua\udump\cuihua_ora_2444.trc

Sat May 05 01:34:27 2012

ORACLE V10.2.0.1.0 – Production vsnsta=0

vsnsql=14 vsnxtr=3

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 – Production

With the Partitioning, OLAP and Data Mining options

Windows XP Version V5.1 Service Pack 2

CPU : 2 – type 586

Process Affinity : 0×00000000

Memory (Avail/Total): Ph:963M/2030M, Ph+PgF:2334M/3921M, VA:1269M/2047M

Instance name: cuihua

Redo thread mounted by this instance: 1

Oracle process number: 30

Windows thread id: 2444, image: ORACLE.EXE (SHAD)

*** 2012-05-05 01:34:27.609

*** ACTION NAME:(Command Window – New) 2012-05-05 01:34:27.546

*** MODULE NAME:(PL/SQL Developer) 2012-05-05 01:34:27.546

*** SERVICE NAME:(cuihua) 2012-05-05 01:34:27.546

*** SESSION ID:(130.15) 2012-05-05 01:34:27.546

Received ORADEBUG command ‘dump processstate 10′ from process Windows thread id: 800, image:

===================================================

PROCESS STATE

————-

Process global information:

process: 33E51F1C, call: 317DD38C, xact: 00000000, curses: 33F1D17C, usrses: 33F1D17C

—————————————-

SO: 33E51F1C, type: 2, owner: 00000000, flag: INIT/-/-/0×00

(process) Oracle pid=30, calls cur/top: 317DD38C/317DD38C, flag: (0) -

int error: 0, call error: 0, sess error: 0, txn error 0

(post info) last post received: 0 0 0

last post received-location: No post

last process to post me: none

last post sent: 0 0 0

last post sent-location: No post

last process posted by me: none

(latch info) wait_event=0 bits=0

Location from where call was made: kglpnal: child: alloc space: latch

Context saved from call: 1

waiting for 3213df50 Child library cache pin level=6 child#=2

Location from where latch is held: kglpndl: child

Context saved from call: 1

state=busy, wlstate=free

waiters [orapid (seconds since: put on list, posted, alive check)]:

10 (49, 1336152864, 49)

30 (24, 1336152864, 24)

waiter count=2

gotten 348654 times wait, failed first 2 sleeps 1

gotten 0 times nowait, failed: 0

on wait list for 3213df50

Process Group: DEFAULT, pseudo proc: 33E7F368

O/S info: user: SYSTEM, term: Y8908CUIHUA, ospid: 2444

OSD pid info: Windows thread id: 2444, image: ORACLE.EXE (SHAD)

……省略显示其他内容

注意上述trace文件中有如下内容：

waiting for 3213df50 Child library cache pin level=6 child#=2

但注意这里没有holding Child library cache！所以我们已经证明了硬解析会持有Child library cache pin，但是是在释放了Child library cache的情况下，也就是说硬解析的时候不会同时持有Child library cache和Child library cache pin。

第四步：我们来证明软解析也会去持有Child library cache，所以过度的软解析实际上也会导致Child library cache的争用：

先到session 1、session 2和session 3中去做一下准备工作：

Session 1:

SQL> select ‘oradebug poke 0x’ || addr || ‘ 4 0×00000001′ from v$latch_children where name=’library cache’;

‘ORADEBUGPOKE0X’||ADDR||’40X00

————————————-

oradebug poke 0x3213DE80 4 0×00000001

oradebug poke 0x3213DE18 4 0×00000001

oradebug poke 0x3213DDB0 4 0×00000001

Session 2:

SQL> show parameter session_cache;

NAME TYPE VALUE

———————————— ———– ——————————

session_cached_cursors integer 20

这里session_cached_cursors的值大于0，所以这里执行同样的sql三次以上的时候才会是软软解析，如果同样的sql的执行次数大于一次但不超过三次，则是软解析。

SQL> select * from scott.emp;

EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO

—– ———- ——— —– ———– ——— ——— ——

7981 CUIHUA 7981

7369 SMITH CLERK 7902 1980-12-17 800.00 20

7499 ALLEN SALESMAN 7698 1981-2-20 1600.00 300.00 30

7521 WARD SALESMAN 7698 1981-2-22 1250.00 500.00 30

7566 JONES MANAGER 7839 1981-4-2 2975.00 20

7654 MARTIN SALESMAN 7698 1981-9-28 1250.00 1400.00 30

7698 BLAKE MANAGER 7839 1981-5-1 2850.00 30

7782 CLARK MANAGER 7839 1981-6-9 2450.00 10

7788 SCOTT ANALYST 7566 1987-4-19 3000.00 20

7839 KING PRESIDENT 1981-11-17 5000.00 10

7844 TURNER SALESMAN 7698 1981-9-8 1500.00 0.00 30

7876 ADAMS CLERK 7788 1987-5-23 1100.00 20

7800 JAME4 CLERK 7698 1981-12-3 950.00 30

13 rows selected

注意这里子cursor和执行次数均为1：

SQL> select sql_text, SQL_ID, VERSION_COUNT,executions from v$sqlarea where sql_text like ‘select * from scott.emp%’;

SQL_TEXT SQL_ID VERSION_COUNT EXECUTIONS

——————————————————————————– ————- ————- ———-

select * from scott.emp dzk32w36udhc5 1 1

SQL> select PLAN_HASH_VALUE, CHILD_NUMBER from v$sql where sql_id=’dzk32w36udhc5′;

PLAN_HASH_VALUE CHILD_NUMBER

————— ————

3956160932 0

SQL> select sid from v$mystat where rownum=1;

SID

———-

134

SQL> select spid from v$process where addr in (select paddr from v$session where sid=134);

SPID

————

2740

Session 3:

SQL> oradebug setospid 2740

Oracle pid: 30, Windows thread id: 2740, image: ORACLE.EXE (SHAD)

接着我们回到session 1，去手工持有所有的Child library cache：

Session 1:

SQL> oradebug setmypid

已处理的语句

SQL> oradebug poke 0x3213DE80 4 0×00000001

BEFORE: [3213DE80, 3213DE84) = 00000000

AFTER: [3213DE80, 3213DE84) = 00000001

SQL> oradebug poke 0x3213DE18 4 0x00000001

BEFORE: [3213DE18, 3213DE1C) = 00000000

AFTER: [3213DE18, 3213DE1C) = 00000001

SQL> oradebug poke 0x3213DDB0 4 0x00000001

BEFORE: [3213DDB0, 3213DDB4) = 00000000

AFTER: [3213DDB0, 3213DDB4) = 00000001

接着到session 2去执行一下我们刚才已经在session 1中执行过的sql，这里也会hang住：

Session 2:

SQL> select * from scott.emp;

……这里hang住了

接着我们到session 3中去对session 2做一下process dump：

Session 3:

SQL> oradebug dump processstate 10

已处理的语句

SQL> oradebug tracefile_name

d:\oracle\admin\cuihua\udump\cuihua_ora_2740.trc

d:\oracle\admin\cuihua\udump\cuihua_ora_2740.trc的内容：

Dump file d:\oracle\admin\cuihua\udump\cuihua_ora_2740.trc

Thu Jan 28 09:08:16 2010

ORACLE V10.2.0.1.0 - Production vsnsta=0

vsnsql=14 vsnxtr=3

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production

With the Partitioning, OLAP and Data Mining options

Windows XP Version V5.1 Service Pack 2

CPU : 2 - type 586

Process Affinity : 0x00000000

Memory (Avail/Total): Ph:1387M/2030M, Ph+PgF:2882M/3921M, VA:1272M/2047M

Instance name: cuihua

Redo thread mounted by this instance: 1

Oracle process number: 24

Windows thread id: 2740, image: ORACLE.EXE (SHAD)

*** SERVICE NAME:(cuihua) 2010-01-28 09:08:16.375

*** SESSION ID:(140.4) 2010-01-28 09:08:16.375

Memory Notification: Library Cache Object loaded into SGA

Heap size 2210K exceeds notification threshold (2048K)

LIBRARY OBJECT HANDLE: handle=33872c70 mutex=33872D24(0)

name=XDB.XDbD/PLZ01TcHgNAgAIIegtw==

hash=e0f82b0c545a707da230a62675d34c80 timestamp=08-30-2005 14:28:09

namespace=XDBS flags=KGHP/TIM/SML/[02000000]

kkkk-dddd-llll=0000-0000-0000 lock=S pin=S latch#=2 hpc=0002 hlc=0002

lwt=33872CCC[33872CCC,33872CCC] ltm=33872CD4[33872CD4,33872CD4]

pwt=33872CB0[33872CB0,33872CB0] ptm=33872CB8[33872CB8,33872CB8]

ref=33872CEC[33872CEC,33872CEC] lnd=33872CF8[33872CF8,33872CF8]

LIBRARY OBJECT: object=303c0ba0

type=XDBS flags=EXS/LOC[0005] pflags=[0000] status=VALD load=X

DATA BLOCKS:

data# heap pointer status pins change whr alloc(K) size(K)

—– ——– ——– ——— —- —— — ——– ——–

0 33872c00 303c0c5c I/P/A/-/- 0 NONE 00 0.34 0.00

1 303c0c98 3038daa8 I/P/A/-/- 1 NONE 00 2210.98 2224.10

Dump file d:\oracle\admin\cuihua\udump\cuihua_ora_2740.trc

Sat May 05 08:48:42 2012

ORACLE V10.2.0.1.0 – Production vsnsta=0

vsnsql=14 vsnxtr=3

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 – Production

With the Partitioning, OLAP and Data Mining options

Windows XP Version V5.1 Service Pack 2

CPU : 2 – type 586

Process Affinity : 0×00000000

Memory (Avail/Total): Ph:1290M/2030M, Ph+PgF:2663M/3921M, VA:1268M/2047M

Instance name: cuihua

Redo thread mounted by this instance: 1

Oracle process number: 30

Windows thread id: 2740, image: ORACLE.EXE (SHAD)

*** 2012-05-05 08:48:42.781

*** ACTION NAME:(Command Window – New) 2012-05-05 08:48:42.687

*** MODULE NAME:(PL/SQL Developer) 2012-05-05 08:48:42.687

*** SERVICE NAME:(cuihua) 2012-05-05 08:48:42.687

*** SESSION ID:(134.7) 2012-05-05 08:48:42.687

Received ORADEBUG command ‘dump processstate 10′ from process Windows thread id: 400, image:

===================================================

PROCESS STATE

————-

Process global information:

process: 33E51F1C, call: 317C80A0, xact: 00000000, curses: 33F21C9C, usrses: 33F21C9C

—————————————-

SO: 33E51F1C, type: 2, owner: 00000000, flag: INIT/-/-/0×00

(process) Oracle pid=30, calls cur/top: 317C80A0/317C80A0, flag: (0) -

int error: 0, call error: 0, sess error: 0, txn error 0

(post info) last post received: 0 0 0

last post received-location: No post

last process to post me: none

last post sent: 0 0 0

last post sent-location: No post

last process posted by me: none

(latch info) wait_event=0 bits=0

Location from where call was made: kglpin: child: heap processing: latch

Context saved from call: 1

waiting for 3213de18 Child library cache level=5 child#=2

Location from where latch is held: kglpndl: child: after processing: latch

Context saved from call: 1

state=busy, wlstate=free

waiters [orapid (seconds since: put on list, posted, alive check)]:

30 (39, 1336178921, 39)

waiter count=1

gotten 179887 times wait, failed first 15 sleeps 1

gotten 206 times nowait, failed: 0

on wait list for 3213de18

Process Group: DEFAULT, pseudo proc: 33E7F368

O/S info: user: SYSTEM, term: Y8908CUIHUA, ospid: 2740

OSD pid info: Windows thread id: 2740, image: ORACLE.EXE (SHAD)

……省略显示其他内容

注意上述trace文件中有如下内容：

waiting for 3213de18 Child library cache level=5 child#=2

所以我们已经证明了软解析也会去持有Child library cache（这个其实很正常，因为软解析还是要扫描library cache object handle链表的嘛），即过度的软解析实际上也会导致Child library cache的争用。

手工释放上述Child library cache后回到session 2，刚才hang住的sql已恢复正常:

SQL> select * from scott.emp;

EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO

—– ———- ——— —– ———– ——— ——— ——

7981 CUIHUA 7981

7369 SMITH CLERK 7902 1980-12-17 800.00 20

7499 ALLEN SALESMAN 7698 1981-2-20 1600.00 300.00 30

7521 WARD SALESMAN 7698 1981-2-22 1250.00 500.00 30

7566 JONES MANAGER 7839 1981-4-2 2975.00 20

7654 MARTIN SALESMAN 7698 1981-9-28 1250.00 1400.00 30

7698 BLAKE MANAGER 7839 1981-5-1 2850.00 30

7782 CLARK MANAGER 7839 1981-6-9 2450.00 10

7788 SCOTT ANALYST 7566 1987-4-19 3000.00 20

7839 KING PRESIDENT 1981-11-17 5000.00 10

7844 TURNER SALESMAN 7698 1981-9-8 1500.00 0.00 30

7876 ADAMS CLERK 7788 1987-5-23 1100.00 20

7800 JAME4 CLERK 7698 1981-12-3 950.00 30

13 rows selected

从如下结果可以看到，子cursor的数量还是1，执行次数变成了2，即刚才第二次执行的sql毫无疑问是软解析：

SQL> select sql_text, SQL_ID, VERSION_COUNT,executions from v$sqlarea where sql_text like ‘select * from scott.emp%’;

SQL_TEXT SQL_ID VERSION_COUNT EXECUTIONS

——————————————————————————– ————- ————- ———-

select * from scott.emp dzk32w36udhc5 1 2

第五步：我们来证明软解析还是会去持有Child library cache lock，但是是在释放了Child library cache的情况下，也就是说软解析会去持有Child library cache lock，但不会同时持有Child library cache和Child library cache lock：

证明步骤和思路与第二步一模一样，这里不再赘述，我们直接来看相关的process dump的trace文件：

d:\oracle\admin\cuihua\udump\cuihua_ora_2988.trc的内容：

Dump file d:\oracle\admin\cuihua\udump\cuihua_ora_2988.trc

Sat May 05 01:50:36 2012

ORACLE V10.2.0.1.0 – Production vsnsta=0

vsnsql=14 vsnxtr=3

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 – Production

With the Partitioning, OLAP and Data Mining options

Windows XP Version V5.1 Service Pack 2

CPU : 2 – type 586

Process Affinity : 0×00000000

Memory (Avail/Total): Ph:1031M/2030M, Ph+PgF:2330M/3921M, VA:1269M/2047M

Instance name: cuihua

Redo thread mounted by this instance: 1

Oracle process number: 24

Windows thread id: 2988, image: ORACLE.EXE (SHAD)

*** 2012-05-05 01:50:36.531

*** ACTION NAME:(Command Window – New) 2012-05-05 01:50:36.468

*** MODULE NAME:(PL/SQL Developer) 2012-05-05 01:50:36.468

*** SERVICE NAME:(cuihua) 2012-05-05 01:50:36.468

*** SESSION ID:(132.36) 2012-05-05 01:50:36.468

Received ORADEBUG command ‘dump processstate 10′ from process Windows thread id: 972, image:

===================================================

PROCESS STATE

————-

Process global information:

process: 33E4FB7C, call: 33F61154, xact: 00000000, curses: 33F1F70C, usrses: 33F1F70C

—————————————-

SO: 33E4FB7C, type: 2, owner: 00000000, flag: INIT/-/-/0×00

(process) Oracle pid=24, calls cur/top: 33F61154/33F61154, flag: (0) -

int error: 0, call error: 0, sess error: 0, txn error 0

(post info) last post received: 0 0 0

last post received-location: No post

last process to post me: none

last post sent: 0 0 0

last post sent-location: No post

last process posted by me: none

(latch info) wait_event=0 bits=0

Location from where call was made: kgllkdl: child: cleanup: latch

Context saved from call: 2

waiting for 3213e0f0 Child library cache lock level=6 child#=1

Location from where latch is held: kgllkdl: child: cleanup: latch

Context saved from call: 2

state=busy, wlstate=free

waiters [orapid (seconds since: put on list, posted, alive check)]:

25 (123, 1336153833, 123)

27 (123, 1336153833, 123)

11 (120, 1336153833, 120)

20 (114, 1336153833, 114)

19 (111, 1336153833, 111)

24 (39, 1336153833, 39)

waiter count=6

gotten 261770 times wait, failed first 74 sleeps 22

gotten 0 times nowait, failed: 0

on wait list for 3213e0f0

Process Group: DEFAULT, pseudo proc: 33E7F368

O/S info: user: SYSTEM, term: Y8908CUIHUA, ospid: 2988

OSD pid info: Windows thread id: 2988, image: ORACLE.EXE (SHAD)

……省略显示其他内容

注意上述trace文件中有如下内容：

waiting for 3213e0f0 Child library cache lock level=6 child#=1

但注意这里没有holding Child library cache！所以我们已经证明了软解析依然会持有Child library cache lock，但是是在释放了Child library cache的情况下，也就是说软解析会去持有Child library cache lock，但不会同时持有Child library cache和Child library cache lock。

第六步：我们来证明软解析还是会去持有Child library cache pin，但是是在释放了Child library cache的情况下，也就是说软解析会去持有Child library cache pin，但不会同时持有Child library cache和Child library cache pin：

证明步骤和思路与第五步一模一样，这里不再赘述。

结合我文章开头提到的那三篇文章（尤其是大熊的那篇文章）和上面的六步证明过程，我们得出如下关于硬解析和软解析时latch持有情况的结论（这个结论是近似的，并没有包括所有的情况）：

1、SQL在硬解析的时候，会先去持有Child library cache以扫描library cache object handle链表，接着会释放Child library cache（因为找不到相关的library cache object handle），接下来会再次持有Child library cache（因为要修改library cache object handle链表），然后在不释放Child library cache的情况下进而去持有Child shared pool以分配内存，接着释放Child shared pool（因为已经分配完了），接着再释放Child library cache；然后因为要以null模式获得library cache lock，所以要先持有Child library cache lock；接着要把相关sql的执行计划load到对应的子cursor的library cache object handle中，即要以exclusive模式获得library cache pin，所以要先持有Child library cache pin；

2、SQL在软解析的时候和硬解析类似，只不过不需要持有Child shared pool并且持有Child library cache的时间会更短。

最后我们来说一下硬解析和软解析在latch争用情况下的本质区别：

1、软解析不会导致Child shared pool的争用；

2、硬解析跟软解析比会导致更为剧烈的Child library cache的争用，这个当然是因为硬解析在不释放Child library cache的情况下进而会去持有Child shared pool。

解决RAC环境下ORA-12545连接错误一例

Cui Hua — Thu, 03 May 2012 07:11:22 +0000

11gR2 RAC两节点的环境，我本机用SCAN VIP连的时候发现连不上了，不断尝试多次，始终报同样的错误ORA-12545：

C:\Documents and Settings\cuihua>sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on 星期四 5月 3 10:53:00 2012

SQL> conn sys/oracle@nbsdev as sysdba;

ERROR:

ORA-12545: 因目标主机或对象不存在, 连接失败

nbsdev在我本机的tnsnames.ora中的配置为：

nbsdev =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = 10.1.15.86)(PORT = 1522))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = NBSDEV)

)

虽然连不上，但tnsping可以ping通，因为tnsping只检查IP地址和端口是否能连通，至于数据库实例状态，监听注册了哪些服务这些，它是不检查的：

C:\Documents and Settings\cuihua>tnsping nbsdev

TNS Ping Utility for 32-bit Windows: Version 11.2.0.1.0 – Production on 03-5月 -

2012 10:43:00

已使用的参数文件:

C:\app\cuihua\product\11.2.0\dbhome_1\network\admin\sqlnet.ora

已使用 TNSNAMES 适配器来解析别名

尝试连接 (DESCRIPTION = (FAILOVER=ON) (ADDRESS = (PROTOCOL = TCP)(HOST = 10.1.15.86)(PORT = 1522)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = NBSDEV)))

OK (30 毫秒)

如下是NBSDEV在database server端的相关设置：

grid:/nbsdu01/app/11.2/network/admin>cat /etc/hosts

# @(#)47 1.2 src/bos/usr/sbin/netstart/hosts, cmdnet, bos61D, d2007_49A2 10/1/07 13:57:52

省略显示相关内容……

#RAC

10.1.15.64 P550-05-LA

10.1.15.84 P550-05-LA-vip

9.2.1.64 P550-05-LA-priv

10.1.15.65 P550-05-LB

10.1.15.85 P550-05-LB-vip

9.2.1.65 P550-05-LB-priv

10.1.15.86 nbsdev-scan

grid:/nbsdu01/app/11.2/network/admin>lsnrctl status LISTENER_SCAN1

LSNRCTL for IBM/AIX RISC System/6000: Version 11.2.0.1.0 – Production on 03-MAY-2012 11:28:16

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN1)))

STATUS of the LISTENER

————————

Alias LISTENER_SCAN1

Version TNSLSNR for IBM/AIX RISC System/6000: Version 11.2.0.1.0 – Production

Start Date 03-MAY-2012 11:27:07

Uptime 0 days 0 hr. 1 min. 9 sec

Trace Level off

Security ON: Local OS Authentication

SNMP ON

Listener Parameter File /nbsdu01/app/11.2/network/admin/listener.ora

Listener Log File /nbsdu01/app/grid/diag/tnslsnr/P550-05-LA/listener_scan1/alert/log.xml

Listening Endpoints Summary…

(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER_SCAN1)))

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.1.15.86)(PORT=1522)))

Services Summary…

Service “NBSDEV” has 2 instance(s).

Instance “NBSDEV1″, status READY, has 1 handler(s) for this service…

Instance “NBSDEV2″, status READY, has 1 handler(s) for this service…

Service “NBSDEVXDB” has 2 instance(s).

Instance “NBSDEV1″, status READY, has 1 handler(s) for this service…

Instance “NBSDEV2″, status READY, has 1 handler(s) for this service…

The command completed successfully

现在的状况是看起来一切正常，但就是连不上。

我们来仔细检查一下SCAN Listener的状况：

grid:/nbsdu01/app/11.2/network/admin>lsnrctl service LISTENER_SCAN1

LSNRCTL for IBM/AIX RISC System/6000: Version 11.2.0.1.0 – Production on 03-MAY-2012 11:28:28

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN1)))

Services Summary…

Service “NBSDEV” has 2 instance(s).

Instance “NBSDEV1″, status READY, has 1 handler(s) for this service…

Handler(s):

“DEDICATED” established:0 refused:0 state:ready

REMOTE SERVER

(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.1.15.84)(PORT=1522)))

Instance “NBSDEV2″, status READY, has 1 handler(s) for this service…

Handler(s):

“DEDICATED” established:0 refused:0 state:blocked

REMOTE SERVER

(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.1.15.84)(PORT=1522)))

Service “NBSDEVXDB” has 2 instance(s).

Instance “NBSDEV1″, status READY, has 1 handler(s) for this service…

Handler(s):

“D000″ established:0 refused:0 current:0 max:1022 state:ready

DISPATCHER

(ADDRESS=(PROTOCOL=tcp)(HOST=P550-05-LA)(PORT=64296))

Instance “NBSDEV2″, status READY, has 1 handler(s) for this service…

Handler(s):

“D000″ established:0 refused:0 current:0 max:1022 state:ready

DISPATCHER

(ADDRESS=(PROTOCOL=tcp)(HOST=P550-05-LB)(PORT=43555))

The command completed successfully

从上述结果里我们可以看到，现在节点2上面的NBSDEV2的Handler的状态为blocked且HOST地址错了――这里HOST地址明显应该是10.1.15.85。

我们登陆一下节点2，看一下local listener的状态：

grid:/home/grid>lsnrctl status

LSNRCTL for IBM/AIX RISC System/6000: Version 11.2.0.1.0 – Production on 03-MAY-2012 11:31:40

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER)))

STATUS of the LISTENER

————————

Alias LISTENER

Version TNSLSNR for IBM/AIX RISC System/6000: Version 11.2.0.1.0 – Production

Start Date 28-APR-2012 17:34:03

Uptime 4 days 17 hr. 57 min. 37 sec

Trace Level off

Security ON: Local OS Authentication

SNMP ON

Listener Parameter File /nbsdu01/app/11.2/network/admin/listener.ora

Listener Log File /nbsdu01/app/grid/diag/tnslsnr/P550-05-LB/listener/alert/log.xml

Listening Endpoints Summary…

(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER)))

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.1.15.65)(PORT=1522)))

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.1.15.85)(PORT=1522)))

Services Summary…

Service “+ASM” has 1 instance(s).

Instance “+ASM2″, status READY, has 1 handler(s) for this service…

The command completed successfully

从结果里可以看到，实例NBSDEV2的动态注册并没有成功，只有ASM实例，这个不对。

我们重启一下节点2上的local listener：

grid:/home/grid>lsnrctl stop

LSNRCTL for IBM/AIX RISC System/6000: Version 11.2.0.1.0 – Production on 03-MAY-2012 11:32:50

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER)))

The command completed successfully

grid:/home/grid>lsnrctl start

LSNRCTL for IBM/AIX RISC System/6000: Version 11.2.0.1.0 – Production on 03-MAY-2012 11:32:54

Starting /nbsdu01/app/11.2/bin/tnslsnr: please wait…

TNSLSNR for IBM/AIX RISC System/6000: Version 11.2.0.1.0 – Production

System parameter file is /nbsdu01/app/11.2/network/admin/listener.ora

Log messages written to /nbsdu01/app/grid/diag/tnslsnr/P550-05-LB/listener/alert/log.xml

Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER)))

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER)))

STATUS of the LISTENER

————————

Alias LISTENER

Version TNSLSNR for IBM/AIX RISC System/6000: Version 11.2.0.1.0 – Production

Start Date 03-MAY-2012 11:32:55

Uptime 0 days 0 hr. 0 min. 0 sec

Trace Level off

Security ON: Local OS Authentication

SNMP ON

Listener Parameter File /nbsdu01/app/11.2/network/admin/listener.ora

Listener Log File /nbsdu01/app/grid/diag/tnslsnr/P550-05-LB/listener/alert/log.xml

Listening Endpoints Summary…

(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER)))

The listener supports no services

The command completed successfully

重启完后现在的状态就对了：

grid:/home/grid>lsnrctl status

LSNRCTL for IBM/AIX RISC System/6000: Version 11.2.0.1.0 – Production on 03-MAY-2012 11:34:10

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER)))

STATUS of the LISTENER

————————

Alias LISTENER

Version TNSLSNR for IBM/AIX RISC System/6000: Version 11.2.0.1.0 – Production

Start Date 03-MAY-2012 11:32:55

Uptime 0 days 0 hr. 1 min. 15 sec

Trace Level off

Security ON: Local OS Authentication

SNMP ON

Listener Parameter File /nbsdu01/app/11.2/network/admin/listener.ora

Listener Log File /nbsdu01/app/grid/diag/tnslsnr/P550-05-LB/listener/alert/log.xml

Listening Endpoints Summary…

(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER)))

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.1.15.65)(PORT=1522)))

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.1.15.85)(PORT=1522)))

Services Summary…

Service “+ASM” has 1 instance(s).

Instance “+ASM2″, status READY, has 1 handler(s) for this service…

Service “NBSDEV” has 1 instance(s).

Instance “NBSDEV2″, status READY, has 1 handler(s) for this service…

Service “NBSDEVXDB” has 1 instance(s).

Instance “NBSDEV2″, status READY, has 1 handler(s) for this service…

The command completed successfully

再次回到节点1，现在我们再来看一下SCAN Listener的状态：

grid:/nbsdu01/app/11.2/network/admin>lsnrctl service LISTENER_SCAN1

LSNRCTL for IBM/AIX RISC System/6000: Version 11.2.0.1.0 – Production on 03-MAY-2012 11:34:52

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN1)))

Services Summary…

Service “NBSDEV” has 2 instance(s).

Instance “NBSDEV1″, status READY, has 1 handler(s) for this service…

Handler(s):

“DEDICATED” established:0 refused:0 state:ready

REMOTE SERVER

(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.1.15.84)(PORT=1522)))

Instance “NBSDEV2″, status READY, has 1 handler(s) for this service…

Handler(s):

“DEDICATED” established:0 refused:0 state:ready

REMOTE SERVER

(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.1.15.85)(PORT=1522)))

Service “NBSDEVXDB” has 2 instance(s).

Instance “NBSDEV1″, status READY, has 1 handler(s) for this service…

Handler(s):

“D000″ established:0 refused:0 current:0 max:1022 state:ready

DISPATCHER

(ADDRESS=(PROTOCOL=tcp)(HOST=P550-05-LA)(PORT=64296))

Instance “NBSDEV2″, status READY, has 1 handler(s) for this service…

Handler(s):

“D000″ established:0 refused:0 current:0 max:1022 state:ready

DISPATCHER

(ADDRESS=(PROTOCOL=tcp)(HOST=P550-05-LB)(PORT=43555))

The command completed successfully

从结果里我们可以看到，现在NBSDEV2的Handler的状态已经变成了ready且HOST地址也变成了10.1.15.85。

再次在我本机上尝试连接NBSDEV，刚才的报错ORA-12545已不复存在，我们又可以连上了：

SQL> conn sys/oracle@nbsdev as sysdba;

已连接。

SQL> show parameter instance_name;

NAME TYPE VALUE

———————————— ———– ——————————

instance_name string NBSDEV1

从整个诊断过程来看，在用SCAN VIP连接的时候，Oracle似乎是在我反复尝试的情况下，始终都将我的连接redirect到节点2上，又因为节点2在SCAN Listener上注册的HOST地址不对，所以Oracle这里报错“ORA-12545: 因目标主机或对象不存在, 连接失败”，这个跟我心目中SCAN VIP的原理不太一样。节点2有问题，你就让我连节点1好了，干嘛要在我反复尝试的情况下始终报错ORA-12545呢？

现在我们手工把节点2上的local listener停掉：

grid:/home/grid>lsnrctl stop

LSNRCTL for IBM/AIX RISC System/6000: Version 11.2.0.1.0 – Production on 03-MAY-2012 14:08:45

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER)))

The command completed successfully

再次回到节点1，查看一下SCAN Listener的状态：

grid:/home/grid>lsnrctl service LISTENER_SCAN1

LSNRCTL for IBM/AIX RISC System/6000: Version 11.2.0.1.0 – Production on 03-MAY-2012 14:10:26

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN1)))

Services Summary…

Service “NBSDEV” has 2 instance(s).

Instance “NBSDEV1″, status READY, has 1 handler(s) for this service…

Handler(s):

“DEDICATED” established:23 refused:0 state:ready

REMOTE SERVER

(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.1.15.84)(PORT=1522)))

Instance “NBSDEV2″, status READY, has 1 handler(s) for this service…

Handler(s):

“DEDICATED” established:3 refused:0 state:blocked

REMOTE SERVER

(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.1.15.85)(PORT=1522)))

Service “NBSDEVXDB” has 2 instance(s).

Instance “NBSDEV1″, status READY, has 1 handler(s) for this service…

Handler(s):

“D000″ established:0 refused:0 current:0 max:1022 state:ready

DISPATCHER

(ADDRESS=(PROTOCOL=tcp)(HOST=P550-05-LA)(PORT=64296))

Instance “NBSDEV2″, status READY, has 1 handler(s) for this service…

Handler(s):

“D000″ established:0 refused:0 current:0 max:1022 state:ready

DISPATCHER

(ADDRESS=(PROTOCOL=tcp)(HOST=P550-05-LB)(PORT=43555))

The command completed successfully

从上述结果里我们可以看到，当我把节点2上的local listener停掉后，节点1上SCAN Listener中节点2对应的Handler的状态已经变成了blocked，但此时HOST地址是对的。

从如下结果我们可以看到——虽然节点1上SCAN Listener中节点2对应的Handler的状态已经变成了blocked，但因为HOST地址是对的，所以当我在本机以SCAN VIP连接的时候还是可以连上，Oracle这里正确的将我的连接redirect到了节点1上：

SQL> conn sys/oracle@nbsdev as sysdba;

Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.1.0

Connected as SYS

SQL> show parameter instance_name;

NAME TYPE VALUE

———————————— ———– ——————————

instance_name string NBSDEV1

RAC环境下的连接管理

Cui Hua — Mon, 02 Apr 2012 09:11:35 +0000

这篇文章正在修改，即将被放到OTN/CN上。

This article is under review, will be put on OTN/CN in a very short time.

关于SCN另外两个有趣的知识点

Cui Hua — Sat, 24 Mar 2012 15:48:42 +0000

首先声明一下，这篇文章的结论来源于我昨天在机场接姗姗妈的时候跟大熊的讨论，并不是我的原创。

在步入正题之前，先普及一下关于Oracle里SCN的基本知识点：

1、Oracle的SCN在每秒16384次commit的情况下可以维持534年，每秒16384次commit是Oracle早先认为的任何系统的极限commit强度；

2、Oracle里SCN的起点是1988年1月1日；

3、_minimum_giga_scn=n的含义是把SCN往前推进到nG，但请注意，只有在SCN小于nG的时候才会用到这个隐含参数，反之则Oracle会置这个隐含参数于不顾。

好了，我们进入正题，这篇文章里要阐述的两个关于SCN的有趣的知识点如下：

1、SCN会随着dblink从高向低扩散；

2、过大的SCN可能会导致Oracle数据库打不开；

好了，我们来看两个证明上述观点的实例：

一、SCN会随着dblink从高向低扩散：

先连到名为cuihua的10.2.0.1的库：

SQL> conn sys/oracle@cuihua as sysdba;

Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.1.0

Connected as SYS

可以看到系统目前的SCN：

SQL> select dbms_flashback.get_system_change_number() from dual;

DBMS_FLASHBACK.GET_SYSTEM_CHAN

——————————

1073742134

当然，这个SCN会随着时间的推移而增长：

SQL> select dbms_flashback.get_system_change_number() from dual;

DBMS_FLASHBACK.GET_SYSTEM_CHAN

——————————

1073742140

这个库目前的对象数为51831：

SQL> select count(*) from dba_objects;

COUNT(*)

———-

51831

再另起一个session，连到名为cuihua112的11.2.0.1的库：

SQL> conn sys/oracle@cuihua112 as sysdba;

Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.1.0

Connected as SYS

从cuihua112中创建一个到上述10.2.0.1的库cuihua的dblink：

SQL> create public database link cuihua connect to scott identified by tiger using ‘cuihua’;

Database link created

可以看到在cuihua112中，系统目前的SCN仅为2100672：

SQL> select dbms_flashback.get_system_change_number() from dual;

DBMS_FLASHBACK.GET_SYSTEM_CHAN

——————————

2100672

当然，这个SCN会随着时间的推移而增长，但是增长的幅度有限（因为这个库很闲，我什么事情也没做）：

SQL> select dbms_flashback.get_system_change_number() from dual;

DBMS_FLASHBACK.GET_SYSTEM_CHAN

——————————

2100673

接着，我通过刚建的dblink去查一下cuihua中的对象数，结果是51831，和之前的查询结果一致：

SQL> select count(*) from dba_objects@cuihua;

COUNT(*)

———-

51831

接着我们马上再次查询系统的SCN，发现结果已经从之前的2100673猛增到1073742966，这个实际上已经足以证明SCN会随着dblink从高向低扩散：

SQL> select dbms_flashback.get_system_change_number() from dual;

DBMS_FLASHBACK.GET_SYSTEM_CHAN

——————————

1073742966

好了，我们再来看第二个实例：

二、过大的SCN可能会导致Oracle数据库打不开（我只测试了10.2.0.1）

现在这个名为10.2.0.1的库cuihua是可以正常打开的：

SQL> startup pfile=’D:\oracle\oradata\cuihua\initcuihua.ora’

ORACLE 例程已经启动。

Total System Global Area 608174080 bytes

Fixed Size 1250404 bytes

Variable Size 209718172 bytes

Database Buffers 390070272 bytes

Redo Buffers 7135232 bytes

数据库装载完毕。

数据库已经打开。

今天是2012年3月24日：

SQL> select sysdate from dual;

SYSDATE

——————————

2012-3-24 22:04:17

2012年3月24日距离1988年1月1日有290.741935月：

SQL> select months_between (to_date(’20120324′,’YYYYMMDD’),to_date(’19880101′,’YYYYMMDD’) ) “MONTHS” from dual;

MONTHS

———-

290.741935

在每秒16384的极限commit强度下，要超过当前时间（即要超过290.741935月，我这里选用了300），只需要将_minimum_giga_scn递增到12260即可：

SQL> select 16384*60*60*24*31*300/(1024*1024*1024) SCN from dual;

SCN

———-

12260.7421

Shutdown上述库：

SQL> shutdown immediate;

数据库已经关闭。

已经卸载数据库。

ORACLE 例程已经关闭。

修改initcuihua.ora文件，添加*._minimum_giga_scn=12260：

*.undo_management=’AUTO’

*.undo_retention=3600

*.undo_tablespace=’UNDOTBS1′

*.user_dump_dest=’D:\oracle\admin\cuihua\udump’

*._minimum_giga_scn=12260

改完后再启库的时候发现已经启动不了了，但这里Oracle报的错误是莫名其妙的：

SQL> startup pfile=’D:\oracle\oradata\cuihua\initcuihua.ora’

ORACLE 例程已经启动。

Total System Global Area 608174080 bytes

Fixed Size 1250404 bytes

Variable Size 209718172 bytes

Database Buffers 390070272 bytes

Redo Buffers 7135232 bytes

数据库装载完毕。

ORA-01052: 未指定所需的目标 LOG_ARCHIVE_DUPLEX_DEST

SQL> select status from v$instance;

STATUS

————

MOUNTED

SQL> shutdown immediate;

ORA-01109: 数据库未打开

已经卸载数据库。

ORACLE 例程已经关闭。

再在cuihua112中计算一下，不超过当前时间（即不超过290.741935月，我这里选用了280）的_minimum_giga_scn的值应该是11443：

SQL> select 16384*60*60*24*31*280/(1024*1024*1024) SCN from dual;

SCN

———-

11443.3593

修改initcuihua.ora文件，将_minimum_giga_scn的值改为11443：

*.undo_management=’AUTO’

*.undo_retention=3600

*.undo_tablespace=’UNDOTBS1′

*.user_dump_dest=’D:\oracle\admin\cuihua\udump’

*._minimum_giga_scn=11443

改完后上述库又可以成功启动了：

SQL> startup pfile=’D:\oracle\oradata\cuihua\initcuihua.ora’

ORACLE 例程已经启动。

Total System Global Area 608174080 bytes

Fixed Size 1250404 bytes

Variable Size 209718172 bytes

Database Buffers 390070272 bytes

Redo Buffers 7135232 bytes

数据库装载完毕。

数据库已经打开。

SQL> select dbms_flashback.get_system_change_number() from dual;

DBMS_FLASHBACK.GET_SYSTEM_CHAN

——————————

12286827692577

从结果里可以看到，SCN确实被我们推进到了我们想要推进的值：

SQL> select dbms_flashback.get_system_change_number()/(1024*1024*1024) from dual;

DBMS_FLASHBACK.GET_SYSTEM_CHAN

——————————

11443.0000005225

如何用AMDU从不能mount的ASM磁盘组中往外抽取数据文件

Cui Hua — Sun, 04 Mar 2012 10:33:45 +0000

AMDU是Oracle 11g里自带的一个免费的工具，用于分析ASM磁盘组的元数据以及从不能mount的磁盘组中往外抽取数据文件。

“NOTE:553639.1 Placeholder for AMDU binaries and using with ASM 10g”明确指出：AMDU也可用于10g，并提供了可用于10g的AMDU的各个操作系统的版本供大家下载。

AMDU的原理是解析file directory，这一点ODU也是一样，只不过ODU做的更彻底一些，即使file directory全部损坏，ODU也可以把数据文件抽取出来，尽最大的可能挽救用户的数据。

我们来看一个用AMDU从不能mount的磁盘组中往外抽取数据文件的实例：

我们现在shutdown Oracle实例和ASM实例：

[root@bspdev odu]# su – oracle

[oracle@bspdev ~]$ sqlplus ‘/ as sysdba’;

SQL*Plus: Release 11.2.0.1.0 Production on Thu Feb 23 10:43:36 2012

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 – Production

With the Partitioning, Automatic Storage Management, OLAP, Data Mining

and Real Application Testing options

SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> exit

Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 – Production

With the Partitioning, Automatic Storage Management, OLAP, Data Mining

and Real Application Testing options

[oracle@bspdev ~]$ su – grid

Password:

[grid@bspdev ~]$ sqlplus ‘/ as sysasm’;

SQL*Plus: Release 11.2.0.1.0 Production on Thu Feb 23 10:45:05 2012

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 – Production

With the Automatic Storage Management option

SQL> shutdown immediate

ASM diskgroups dismounted

ASM instance shutdown

SQL> exit

Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 – Production

With the Automatic Storage Management option

[grid@bspdev ~]$ crsctl status res

NAME=ora.DATA.dg

TYPE=ora.diskgroup.type

TARGET=OFFLINE

STATE=OFFLINE

NAME=ora.LISTENER.lsnr

TYPE=ora.listener.type

TARGET=ONLINE

STATE=ONLINE on bspdev

NAME=ora.RECO.dg

TYPE=ora.diskgroup.type

TARGET=OFFLINE

STATE=OFFLINE

NAME=ora.asm

TYPE=ora.asm.type

TARGET=OFFLINE

STATE=OFFLINE

NAME=ora.cssd

TYPE=ora.cssd.type

TARGET=ONLINE

STATE=ONLINE on bspdev

NAME=ora.diskmon

TYPE=ora.diskmon.type

TARGET=ONLINE

STATE=ONLINE on bspdev

NAME=ora.ora11g.db

TYPE=ora.database.type

TARGET=OFFLINE

STATE=OFFLINE

在ASM diskgroup不能mount的情况下asmcmd不能使用：

[grid@bspdev ~]$ asmcmd

Connected to an idle instance.

ASMCMD> ls

ASMCMD-08102: no connection to ASM; command requires ASM to run

但此时ODU内嵌的asmcmd是可以使用的，所以我们可以轻易的使用ODU内嵌的asmcmd命令来得到所有的datafile的名称：

[grid@bspdev ~]$ su -

Password:

[root@bspdev ~]# cd /u01/app/oracle/odu

[root@bspdev odu]# ./odu

Oracle Data Unloader:Release 4.2.1

Web: http://www.oracleodu.com

Email: magic007cn@gmail.com

loading default config…….

byte_order little

block_size 8192

block_buffers 1024

db_timezone -7

Invalid db timezone:-7

client_timezone 8

Invalid client timezone:8

asmfile_extract_path /odu/asmfile

data_path data

lob_path /odu/data/lob

charset_name AL32UTF8

ncharset_name AL16UTF16

output_format text

lob_storage infile

clob_byte_order big

trace_level 1

delimiter |

unload_deleted no

file_header_offset 0

is_tru64 no

record_row_addr no

convert_clob_charset yes

use_scanned_lob yes

trim_scanned_blob yes

lob_switch_dir_rows 20000

db_block_checksum yes

db_block_checking yes

rdba_file_bits 10

compatible 10

load config file ‘config.txt’ successful

loading default asm disk file ……

grp# dsk# bsize ausize disksize diskname groupname path

—- —- —– —— ——– ————— ————— ——————————————–

1 0 4096 1024K 9000 DATA_0000 DATA /dev/sda3

1 1 4096 1024K 9000 DATA_0001 DATA /dev/sda5

1 2 4096 1024K 9000 DATA_0002 DATA /dev/sda6

2 0 4096 1024K 9000 RECO_0000 RECO /dev/sda7

2 1 4096 1024K 7288 RECO_0001 RECO /dev/sda8

load asm disk file ‘asmdisk.txt’ successful

loading default control file ……

ts# fn rfn bsize blocks bf offset filename

—- —- —- —– ——– — —— ——————————————–

load control file ‘control.txt’ successful

loading dictionary data……done

loading scanned data……done

ODU> asmcmd

Entering asmcmd module.

ASMCMD> ls

Current directory:

Disk Group

————————————

DATA

RECO

ASMCMD> cd +DATA

Current directory: +DATA

ASMCMD> ls

Current directory: +DATA

Name

—————————————-

ASM

ORA11G

ASMCMD> cd ORA11G

Current directory: +DATA/ORA11G

ASMCMD> ls

Current directory: +DATA/ORA11G

Name

—————————————-

DATAFILE

CONTROLFILE

ONLINELOG

TEMPFILE

PARAMETERFILE

spfileora11g.ora => +DATA.265.747311071

ASMCMD> cd DATAFILE

Current directory: +DATA/ORA11G/DATAFILE

可以看到，当前的第259号（这个259是ASM的internal file number）文件名称为+DATA/ORA11G/DATAFILE / USERS.259.747310451：

ASMCMD> ls

Current directory: +DATA/ORA11G/DATAFILE

Name

—————————————-

SYSTEM.256.747310449

SYSAUX.257.747310449

UNDOTBS1.258.747310451

USERS.259.747310451

MYTEST.266.761050749

GAOZCINDEX.267.770299335

GAOZCINDEX1 => +DATA.267.770299335

GAOZCDATA.268.770299347

GAOZCDATA1 => +DATA.268.770299347

现在我们用AMDU把这个文件给抽出来，注意现在这个文件所在的磁盘组DATA还是处于unmount状态。

用AMDU抽取数据文件的语法非常简单，只需要指定磁盘组所在的设备文件名称（可以用*号模糊匹配），以及磁盘组的名称和待抽取的数据文件号（这里的数据文件号是指ASM的internal file number）就可以了：

[root@bspdev odu]# /u01/app/oracle/bin/amdu -diskstring ‘/dev/sda*’ -extract ‘DATA.259′

amdu_2012_02_23_11_21_34/

进入上述目录，可以看到抽取出的第259号文件DATA_259.f已经生成：

[root@bspdev odu]# cd amdu_2012_02_23_11_21_34

[root@bspdev amdu_2012_02_23_11_21_34]# ls -lrt

total 39744

-rw-r–r–. 1 root root 8600 Feb 23 11:21 report.txt

-rw-r–r–. 1 root root 40640512 Feb 23 11:21 DATA_259.f

我们现在再用ODU把259号文件提出来，跟AMDU做一个对比：

[root@bspdev amdu_2012_02_23_11_21_34]# cd ..

[root@bspdev odu]# ./odu

Oracle Data Unloader:Release 4.2.1

Web: http://www.oracleodu.com

Email: magic007cn@gmail.com

loading default config…….

byte_order little

block_size 8192

block_buffers 1024

db_timezone -7

Invalid db timezone:-7

client_timezone 8

Invalid client timezone:8

asmfile_extract_path /odu/asmfile

data_path data

lob_path /odu/data/lob

charset_name AL32UTF8

ncharset_name AL16UTF16

output_format text

lob_storage infile

clob_byte_order big

trace_level 1

delimiter |

unload_deleted no

file_header_offset 0

is_tru64 no

record_row_addr no

convert_clob_charset yes

use_scanned_lob yes

trim_scanned_blob yes

lob_switch_dir_rows 20000

db_block_checksum yes

db_block_checking yes

rdba_file_bits 10

compatible 10

load config file ‘config.txt’ successful

loading default asm disk file ……

grp# dsk# bsize ausize disksize diskname groupname path

—- —- —– —— ——– ————— ————— ——————————————–

1 0 4096 1024K 9000 DATA_0000 DATA /dev/sda3

1 1 4096 1024K 9000 DATA_0001 DATA /dev/sda5

1 2 4096 1024K 9000 DATA_0002 DATA /dev/sda6

2 0 4096 1024K 9000 RECO_0000 RECO /dev/sda7

2 1 4096 1024K 7288 RECO_0001 RECO /dev/sda8

load asm disk file ‘asmdisk.txt’ successful

loading default control file ……

ts# fn rfn bsize blocks bf offset filename

—- —- —- —– ——– — —— ——————————————–

0 1 1 8192 112640 N 0 +DATA/ORA11G/DATAFILE/SYSTEM.256.747310449

1 2 2 8192 119040 N 0 +DATA/ORA11G/DATAFILE/SYSAUX.257.747310449

2 3 3 8192 70400 N 0 +DATA/ORA11G/DATAFILE/UNDOTBS1.258.747310451

4 4 4 8192 4960 N 0 +DATA/ORA11G/DATAFILE/USERS.259.747310451

load control file ‘oductl.dat’ successful

loading dictionary data……done

loading scanned data……done

ODU> asmcmd

Entering asmcmd module.

注意：ODU的最新版本中extract命令已被copy命令替换了：

ASMCMD> extract asmfile +DATA/ORA11G/DATAFILE/USERS.259.747310451 to /u01/app/oracle/odu/amdu_2012_02_23_11_21_34/user01.dbf

starting extract asm file ‘+DATA/ORA11G/DATAFILE/USERS.259.747310451′ to ‘/u01/app/oracle/odu/amdu_2012_02_23_11_21_34/user01.dbf’,file size is 40640512

asm file extract completed.

ASMCMD> exit

Exiting asmcmd module.

[root@bspdev odu]# cd amdu_2012_02_23_11_21_34

[root@bspdev amdu_2012_02_23_11_21_34]# ls -lrt

total 79476

-rw-r–r–. 1 root root 8600 Feb 23 11:21 report.txt

-rw-r–r–. 1 root root 40640512 Feb 23 11:21 DATA_259.f

-rw-r–r–. 1 root root 40640512 Feb 23 11:27 user01.dbf

从结果里可以看到，两者大小一模一样。

从dbv校验的结果来看，两者内容也是一模一样：

[oracle@bspdev ~]$ dbv file=/u01/app/oracle/odu/amdu_2012_02_23_11_21_34/DATA_259.f blocksize=8192

DBVERIFY: Release 11.2.0.1.0 – Production on Thu Feb 23 11:29:50 2012

DBVERIFY – Verification starting : FILE = /u01/app/oracle/odu/amdu_2012_02_23_11_21_34/DATA_259.f

DBVERIFY – Verification complete

Total Pages Examined : 4960

Total Pages Processed (Data) : 4442

Total Pages Failing (Data) : 0

Total Pages Processed (Index): 33

Total Pages Failing (Index): 0

Total Pages Processed (Other): 334

Total Pages Processed (Seg) : 0

Total Pages Failing (Seg) : 0

Total Pages Empty : 151

Total Pages Marked Corrupt : 0

Total Pages Influx : 0

Total Pages Encrypted : 0

Highest block SCN : 2132237218 (1932.2132237218)

[oracle@bspdev ~]$ dbv file=/u01/app/oracle/odu/amdu_2012_02_23_11_21_34/user01.dbf blocksize=8192

DBVERIFY: Release 11.2.0.1.0 – Production on Thu Feb 23 11:30:11 2012

DBVERIFY – Verification starting : FILE = /u01/app/oracle/odu/amdu_2012_02_23_11_21_34/user01.dbf

DBVERIFY – Verification complete

Total Pages Examined : 4960

Total Pages Processed (Data) : 4442

Total Pages Failing (Data) : 0

Total Pages Processed (Index): 33

Total Pages Failing (Index): 0

Total Pages Processed (Other): 334

Total Pages Processed (Seg) : 0

Total Pages Failing (Seg) : 0

Total Pages Empty : 151

Total Pages Marked Corrupt : 0

Total Pages Influx : 0

Total Pages Encrypted : 0

Highest block SCN : 2132237218 (1932.2132237218)

大师这一次是真的错了

Cui Hua — Mon, 13 Feb 2012 06:50:56 +0000

Jonathan Lewis在他的新书《Oracle Core Essential Internals for DBAs and Developers》的第116页这样描述到：

SQL> select name, level#

2 from v$latch

3 where name in (‘cache buffers lru chain’,'cache buffers chains’)

4 /

NAME LEVEL#

—————————— ———-

cache buffers lru chain 2

cache buffers chains 1

2 rows selected.

The cache buffers chains latch has a lower level than the cache buffers lru chain latch, so we can’t request the cache buffers lru chain latch in willing-to-wait mode if we’re already holding the cache buffers chains latch. Think about what this means: we’re holding the cache buffers chains latch (which I will call the hash latch for the rest of this subsection) because we’ve just searched the hash chain for a buffer and discovered that, for whatever reason, we need to add another buffer to the chain. So we have to acquire the cache buffers lru chain latch (which I will call the lru latch for the rest of this subsection) to move a buffer from the REPL_AUX list to the midpoint of the REPL_MAIN list; but we can’t request it in willing-to-wait mode because we’re already holding a lower-level latch.

大师这里提到了说在持有cache buffers chains latch的情况下Oracle不可能再去持有cache buffers lru chain latch，因为cache buffers lru chain的latch level比cache buffers chains的latch level要大。

事实上是：大师这里刚好搞反了，这是latch level最基本的常识啊，我希望大师在这里用了不少篇幅解释的观点只是他的笔误。

我们来证明一下。我只需证明Oracle在持有cache buffers chains latch，并且没有释放的情况下会去持有cache buffers lru chain latch即可证明Jonathan在这个点上犯了常识性的错误。

先来普及一下在Oracle里如何手工持有一个latch——要么用oradebug poke，要么用oradebug call：

Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.1.0

Connected as SYS

SQL> select count(*) from v$latch_children where name = ‘cache buffers lru chain’;

COUNT(*)

———-

SQL> select count(*) from v$latch_children where name = ‘cache buffers chains’;

COUNT(*)

———-

4096

SQL> select name,level# from v$latch where name in (‘cache buffers lru chain’,'cache buffers chains’);

NAME LEVEL#

—————————————————————- ———-

cache buffers lru chain 2

cache buffers chains 1

SQL> select * from (select addr,to_number(addr,’XXXXXXXXXXXX’),gets,misses from v$latch_children where name = ‘cache buffers lru chain’ order by addr desc) where rownum<5;

ADDR TO_NUMBER(ADDR,’XXXXXXXXXXXX’) GETS MISSES

——– —————————— ———- ———-

3497DE1C 882368028 0 0

3497DD94 882367892 10 0

3497D974 882366836 0 0

3497D8EC 882366700 10 0

现在我先看一下latch地址为3497DE1C的cache buffers lru chain latch：

SQL> oradebug peek 0x3497DE1C 300

[3497DE1C, 3497DF48) = 00000000 00000000 00000091 00000002 00000000 00000000 000

00000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ...

我开始调用kslgetl去持有上述latch：

SQL> oradebug call kslgetl 882368028 1

Function returned 1

持有完毕后再去看一下上述latch，可以看到我用红色标注的地方已经被Oracle改了：

SQL> oradebug peek 0x3497DE1C 300

[3497DE1C, 3497DF48) = 00000014 00000001 00000091 00000002 00000001 0D45D417 000

00000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ...

现在我释放上述latch：

SQL> oradebug call kslfre 882368028

Function returned F0E8358

释放完毕后再去看一下上述latch，可以看到我用红色标注的前4个byte又被Oracle改回来了：

SQL> oradebug peek 0x3497DE1C 300

[3497DE1C, 3497DF48) = 00000000 00000001 00000091 00000002 00000001 0D45D417 000

00000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ...

因为我刚才手工持有、释放了一次cache buffers lru chain latch，所以现在这个latch的willing to wait模式的gets的值从0变成了1：

SQL> select * from (select addr,to_number(addr,'XXXXXXXXXXXX'),gets,misses from v$latch_children where name = 'cache buffers lru chain' order by addr desc) where rownum<5;

ADDR TO_NUMBER(ADDR,'XXXXXXXXXXXX') GETS MISSES

-------- ------------------------------ ---------- ----------

3497DE1C 882368028 1 0

3497DD94 882367892 10 0

3497D974 882366836 0 0

3497D8EC 882366700 10 0

准备工作已经做好，现在我们开始反证的过程。

我们反证的思路是：

我同时开3个session，session 1中先持有所有的cache buffers lru chain latch，session 2在session 1持有完所有的cache buffers lru chain latch后去执行update操作，这个时候session 2一定会hang住，同时我们在session 3中去做session 2的process dump，从session 3的dump文件中即可看到session 2中的latch持有与等待的情况。

先分别到session1、session 2、session 3中做一下准备工作：

Session 1：

SQL> select 'oradebug poke 0x' || addr || ' 4 0x00000001' from v$latch_children where name = 'cache buffers lru chain';

'ORADEBUGPOKE0X'||ADDR||'40X00

-------------------------------------

oradebug poke 0x3497DE1C 4 0x00000001

oradebug poke 0x3497DD94 4 0x00000001

oradebug poke 0x3497D974 4 0x00000001

oradebug poke 0x3497D8EC 4 0x00000001

oradebug poke 0x349710A4 4 0x00000001

oradebug poke 0x3497101C 4 0x00000001

oradebug poke 0x34970BFC 4 0x00000001

oradebug poke 0x34970B74 4 0x00000001

oradebug poke 0x3496432C 4 0x00000001

oradebug poke 0x349642A4 4 0x00000001

oradebug poke 0x34963E84 4 0x00000001

oradebug poke 0x34963DFC 4 0x00000001

oradebug poke 0x349575B4 4 0x00000001

oradebug poke 0x3495752C 4 0x00000001

oradebug poke 0x3495710C 4 0x00000001

oradebug poke 0x34957084 4 0x00000001

oradebug poke 0x3494A83C 4 0x00000001

oradebug poke 0x3494A7B4 4 0x00000001

oradebug poke 0x3494A394 4 0x00000001

oradebug poke 0x3494A30C 4 0x00000001

oradebug poke 0x3493DAC4 4 0x00000001

oradebug poke 0x3493DA3C 4 0x00000001

oradebug poke 0x3493D61C 4 0x00000001

oradebug poke 0x3493D594 4 0x00000001

oradebug poke 0x34930D4C 4 0x00000001

oradebug poke 0x34930CC4 4 0x00000001

oradebug poke 0x349308A4 4 0x00000001

oradebug poke 0x3493081C 4 0x00000001

oradebug poke 0x34923FD4 4 0x00000001

oradebug poke 0x34923F4C 4 0x00000001

oradebug poke 0x34923B2C 4 0x00000001

oradebug poke 0x34923AA4 4 0x00000001

32 rows selected

Session 2：

SQL> select sid from v$mystat where rownum=1;

SID

----------

138

SQL> select spid from v$process where addr in (select paddr from v$session where

sid=138);

SPID

------------------------

5356

Session 3:

SQL> oradebug setospid 5356

Oracle pid: 25, Windows thread id: 5356, image: ORACLE.EXE (SHAD)

准备工作已经做完，现在我们先去session 1中去持有所有的cache buffers lru chain latch：

Session 1：

SQL> oradebug poke 0x3497DE1C 4 0x00000001

BEFORE: [3497DE1C, 3497DE20) = 00000000

AFTER: [3497DE1C, 3497DE20) = 00000001

SQL> oradebug poke 0x3497DD94 4 0x00000001

BEFORE: [3497DD94, 3497DD98) = 00000000

AFTER: [3497DD94, 3497DD98) = 00000001

SQL> oradebug poke 0x3497D974 4 0x00000001

BEFORE: [3497D974, 3497D978) = 00000000

AFTER: [3497D974, 3497D978) = 00000001

SQL> oradebug poke 0x3497D8EC 4 0x00000001

BEFORE: [3497D8EC, 3497D8F0) = 00000000

AFTER: [3497D8EC, 3497D8F0) = 00000001

SQL> oradebug poke 0x349710A4 4 0x00000001

BEFORE: [349710A4, 349710A = 00000000

AFTER: [349710A4, 349710A = 00000001

SQL> oradebug poke 0x3497101C 4 0x00000001

BEFORE: [3497101C, 34971020) = 00000000

AFTER: [3497101C, 34971020) = 00000001

SQL> oradebug poke 0x34970BFC 4 0x00000001

BEFORE: [34970BFC, 34970C00) = 00000000

AFTER: [34970BFC, 34970C00) = 00000001

SQL> oradebug poke 0x34970B74 4 0x00000001

BEFORE: [34970B74, 34970B78) = 00000000

AFTER: [34970B74, 34970B78) = 00000001

SQL> oradebug poke 0x3496432C 4 0x00000001

BEFORE: [3496432C, 34964330) = 00000000

AFTER: [3496432C, 34964330) = 00000001

SQL> oradebug poke 0x349642A4 4 0x00000001

BEFORE: [349642A4, 349642A = 00000000

AFTER: [349642A4, 349642A = 00000001

SQL> oradebug poke 0x34963E84 4 0x00000001

BEFORE: [34963E84, 34963E88) = 00000000

AFTER: [34963E84, 34963E88) = 00000001

SQL> oradebug poke 0x34963DFC 4 0x00000001

BEFORE: [34963DFC, 34963E00) = 00000000

AFTER: [34963DFC, 34963E00) = 00000001

SQL> oradebug poke 0x349575B4 4 0x00000001

BEFORE: [349575B4, 349575B8) = 00000000

AFTER: [349575B4, 349575B8) = 00000001

SQL> oradebug poke 0x3495752C 4 0x00000001

BEFORE: [3495752C, 34957530) = 00000000

AFTER: [3495752C, 34957530) = 00000001

SQL> oradebug poke 0x3495710C 4 0x00000001

BEFORE: [3495710C, 34957110) = 00000000

AFTER: [3495710C, 34957110) = 00000001

SQL> oradebug poke 0x34957084 4 0x00000001

BEFORE: [34957084, 34957088) = 00000000

AFTER: [34957084, 34957088) = 00000001

SQL> oradebug poke 0x3494A83C 4 0x00000001

BEFORE: [3494A83C, 3494A840) = 00000000

AFTER: [3494A83C, 3494A840) = 00000001

SQL> oradebug poke 0x3494A7B4 4 0x00000001

BEFORE: [3494A7B4, 3494A7B8) = 00000000

AFTER: [3494A7B4, 3494A7B8) = 00000001

SQL> oradebug poke 0x3494A394 4 0x00000001

BEFORE: [3494A394, 3494A398) = 00000000

AFTER: [3494A394, 3494A398) = 00000001

SQL> oradebug poke 0x3494A30C 4 0x00000001

BEFORE: [3494A30C, 3494A310) = 00000000

AFTER: [3494A30C, 3494A310) = 00000001

SQL> oradebug poke 0x3493DAC4 4 0x00000001

BEFORE: [3493DAC4, 3493DAC8) = 00000000

AFTER: [3493DAC4, 3493DAC8) = 00000001

SQL> oradebug poke 0x3493DA3C 4 0x00000001

BEFORE: [3493DA3C, 3493DA40) = 00000000

AFTER: [3493DA3C, 3493DA40) = 00000001

SQL> oradebug poke 0x3493D61C 4 0x00000001

BEFORE: [3493D61C, 3493D620) = 00000000

AFTER: [3493D61C, 3493D620) = 00000001

SQL> oradebug poke 0x3493D594 4 0x00000001

BEFORE: [3493D594, 3493D598) = 00000000

AFTER: [3493D594, 3493D598) = 00000001

SQL> oradebug poke 0x34930D4C 4 0x00000001

BEFORE: [34930D4C, 34930D50) = 00000000

AFTER: [34930D4C, 34930D50) = 00000001

SQL> oradebug poke 0x34930CC4 4 0x00000001

BEFORE: [34930CC4, 34930CC8) = 00000000

AFTER: [34930CC4, 34930CC8) = 00000001

SQL> oradebug poke 0x349308A4 4 0x00000001

BEFORE: [349308A4, 349308A = 00000000

AFTER: [349308A4, 349308A = 00000001

SQL> oradebug poke 0x3493081C 4 0x00000001

BEFORE: [3493081C, 34930820) = 00000000

AFTER: [3493081C, 34930820) = 00000001

SQL> oradebug poke 0x34923FD4 4 0x00000001

BEFORE: [34923FD4, 34923FD8) = 00000000

AFTER: [34923FD4, 34923FD8) = 00000001

SQL> oradebug poke 0x34923F4C 4 0x00000001

BEFORE: [34923F4C, 34923F50) = 00000000

AFTER: [34923F4C, 34923F50) = 00000001

SQL> oradebug poke 0x34923B2C 4 0x00000001

BEFORE: [34923B2C, 34923B30) = 00000000

AFTER: [34923B2C, 34923B30) = 00000001

SQL> oradebug poke 0x34923AA4 4 0x00000001

BEFORE: [34923AA4, 34923AA8) = 00000000

AFTER: [34923AA4, 34923AA8) = 00000001

接着我们到session 2去随便执行一条update语句，这个一定会hang住的：

Session 2：

SQL> update scott.emp set ename='CUIHUA2' where empno=7369;

……这里hang住了

接着我们到session 3中去对session 2做一下process dump：

Session 3：

SQL> oradebug dump processstate 10

已处理的语句

SQL> oradebug tracefile_name

c:\app\cuihua\diag\rdbms\cuihua112\cuihua112\trace\cuihua112_ora_5356.trc

最后我们看一下上述trace文件：

Trace file c:\app\cuihua\diag\rdbms\cuihua112\cuihua112\trace\cuihua112_ora_5356.trc

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

Windows XP Version V5.1 Service Pack 2

CPU : 2 - type 586

Process Affinity : 0x0x00000000

Memory (Avail/Total): Ph:654M/2030M, Ph+PgF:1907M/3921M, VA:1143M/2047M

Instance name: cuihua112

Redo thread mounted by this instance: 1

Oracle process number: 25

Windows thread id: 5356, image: ORACLE.EXE (SHAD)

*** 2012-02-13 13:41:39.859

*** SESSION ID:(138.8) 2012-02-13 13:41:39.859

*** CLIENT ID:() 2012-02-13 13:41:39.859

*** SERVICE NAME:(SYS$USERS) 2012-02-13 13:41:39.859

*** MODULE NAME:(sqlplus.exe) 2012-02-13 13:41:39.859

*** ACTION NAME:() 2012-02-13 13:41:39.859

Received ORADEBUG command (#1) 'dump processstate 10' from process 'Windows thread id: 2664, image: '

===================================================

PROCESS STATE

-------------

Process global information:

process: 0x35483BE4, call: 0x357D43F0, xact: 0x00000000, curses: 0x357580BC, usrses: 0x357684FC

----------------------------------------

SO: 0x35483BE4, type: 2, owner: 0x00000000, flag: INIT/-/-/0x00 if: 0x3 c: 0x3

proc=0x35483BE4, name=process, file=ksu.h LINE:11459, pg=0

(process) Oracle pid:25, ser:4, calls cur/top: 0x357D43F0/0x357D1130

flags : (0x0) -

flags2: (0x0), flags3: (0x0)

intr error: 0, call error: 0, sess error: 0, txn error 0

intr queue: empty

ksudlp FALSE at location: 0

(post info) last post received: 0 0 0

last post received-location: No post

last process to post me: none

last post sent: 0 0 0

last post sent-location: No post

last process posted by me: none

(latch info) wait_event=0 bits=2

Location from where call was made: kcb2.h LINE:3601 ID:kcbzgws:

waiting for 3493da3c Child cache buffers lru chain level=2 child#=11

Location from where latch is held: kcbb.h LINE:2063 ID:kcbbic2:

Context saved from call: 0

state=busy [holder orapid=1] wlstate=free [value=0]

waiters [orapid (seconds since: put on list, posted, alive check)]:

31 (34, 1329111699, 34)

25 (27, 1329111699, 27)

waiter count=2

gotten 465 times wait, failed first 0 sleeps 0

gotten 13848 times nowait, failed: 4

possible holder pid = 1 ospid=

on wait list for 3493da3c

holding (efd=23) 34848c10 Child cache buffers chains level=1 child#=2313

Location from where latch is held: kcb2.h LINE:3034 ID:kcbgtcr: kslbegin shared:

Context saved from call: 4265585

state=busy(exclusive) [value=0x20000019, holder orapid=25] wlstate=free [value=0]

Process Group: DEFAULT, pseudo proc: 0x354E2458

O/S info: user: SYSTEM, term: Y8908CUIHUA, ospid: 5356

OSD pid info: Windows thread id: 5356, image: ORACLE.EXE (SHAD)

从trace文件里红色标注的部分我们可以看到：

waiting for 3493da3c Child cache buffers lru chain level=2 child#=11

holding (efd=23) 34848c10 Child cache buffers chains level=1 child#=2313

即Oracle是在持有了cache buffers chains latch的情况下（注意这里是holding，意味着Oracle并没有释放，是正在持有）去持有cache buffers lru chain latch。

所以大师这次是真的错了。

关于timestamp with local time zone

Cui Hua — Wed, 01 Feb 2012 09:58:54 +0000

有朋友问我：Oracle数据迁移时源库和目标库的时区不一样，这对于迁移数据而言是否有影响？

这个是没有影响的。

Oracle里跟时区有关的数据类型有两种，分别是timestamp with time zone和timestamp with local time zone，Oracle分别用13个byte和11个byte来存储他们。

这里面timestamp with time zone没什么好说的，因为里面的时区是用2个byte来固定的存储时区的偏移量，所以源库和目标库的时区即使不一样，对原始数据也没有影响。

timestamp with local time zone跟timestamp with time zone最大的区别就是timestamp with local time zone不会具体存储时区的偏移量，而是会根据dbtimezone和用户插入数据时指定的时区（通常就等于sessiontimezone）之间的差值来调整所存储的时间：

我们来看一个实例：

先来看数据库1：

数据库1：

SQL> select dbtimezone from dual;

DBTIMEZONE

———-

+08:00

SQL> select systimestamp from dual;

SYSTIMESTAMP

——————————————————————————–

01-2月 -12 04.15.54.224786 下午 +08:00

SQL> select sessiontimezone from dual;

SESSIONTIMEZONE

—————————————————————————

+08:00

现在这个库的systimestamp中包含的时区和dbtimezone相同，所以当我插入systimestamp的时候，Oracle 不会对timestamp with local time zone做时间上的调整：

SQL> create table t2(col1 timestamp with local time zone);

Table created

SQL> insert into t2 values(systimestamp);

1 row inserted

SQL> commit;

Commit complete

SQL> select col1,dump(col1) from t2;

COL1 DUMP(COL1)

————————————————– —————————————————————

01-2月 -12 04.18.58.839122 下午 Typ=231 Len=11: 120,112,2,1,17,19,59,50,3,252,80

从结果里我们看到，17减1后是16，也就是下午4点，所以这里是没有发生时间的调整的，原因我上面已经说过了。

我们修改一下sessiontimezone后再插入一条记录，我把sessiontimezone修改为洛杉矶所在的时区：

SQL> ALTER SESSION SET TIME_ZONE = ‘-08:00′;

Session altered

SQL> select sessiontimezone from dual;

SESSIONTIMEZONE

—————————————————————————

-08:00

注意，这个时候不能再插入systimestamp了，systimestamp跟sessiontimezone和dbtimezone没有关系，它只取决于database server端环境变量TZ的设置：

SQL> select systimestamp,current_timestamp from dual;

SYSTIMESTAMP CURRENT_TIMESTAMP

————————————————————– ————————————————-

01-2月 -12 04.37.19.615042 下午 +08:00 01-2月 -12 12.37.19.615109 上午 -08:00

SQL> select * from v$timezone_names where tzname like ‘America/Los%’;

TZNAME TZABBREV

—————————————————————- —————————————————————-

America/Los_Angeles LMT

America/Los_Angeles PST

America/Los_Angeles PDT

America/Los_Angeles PWT

America/Los_Angeles PPT

SQL> insert into t2 values(to_timestamp_tz(’2012-02-01 16:38:19 America/Los_Angeles’,'YYYY-MM-DD HH24:MI:SS TZR’));

1 row inserted

SQL> commit;

Commit complete

SQL> select col1,dump(col1) from t2;

COL1 DUMP(COL1)

————————————————– ——————————————————————————–

01-2月 -12 12.18.58.839122 上午 Typ=231 Len=11: 120,112,2,1,17,19,59,50,3,252,80

01-2月 -12 04.38.19.000000 下午 Typ=231 Len=7: 120,112,2,2,9,39,20

从结果里我们可以看到，之前插入的那条记录显示结果变成了2月1日上午零点18分，这是正常的，因为timestamp with local time zone的显示结果会随着sessiontimezone的改变而改变，洛杉矶滞后于北京16个小时，所以我们在16点18分插入的那条记录的显示结果变成了上午零点18分。

现在我们来解释刚刚插入的第二条记录的显示结果：

插入的时候我们指定了是以洛杉矶当地时间16点38分19秒，而现在的sessiontimezone就是洛杉矶所在的时区，所以第二条记录的显示结果就是16点38分19秒。

现在第二条记录Oracle实际上的存储结果是120,112,2,2,9,39,20，这里因为dbtimezone是+08:00，插入的时候我们指定了是以洛杉矶当地时间（相当于sessiontimezone是-08:00），所以Oracle要对timestamp with local time zone实际存储结果加上sessiontimezone和dbtimezone的差值，也就是16个小时。16点38分19秒加上16是32点38分19秒，也就是第二天早上8点38分19秒，所以这里Oracle实际的存储结果变成了2,2,9,39,20。

我们导出上述表：

oracle:/nbsdata01/oradata/testdb>exp \’sys/oracle@nbsdev as sysdba\’ file=t2.dmp tables=t2

Export: Release 11.2.0.1.0 – Production on Wed Feb 1 17:11:25 2012

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 – 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

Export done in UTF8 character set and AL16UTF16 NCHAR character set

server uses AL32UTF8 character set (possible charset conversion)

About to export specified tables via Conventional Path …

. . exporting table T2 2 rows exported

Export terminated successfully without warnings.

现在我们切换到目标数据库2，这个库里dbtimezone和数据库1的dbtimezone是不一样的，这里我用dbtimezone的差异来模拟时区的差异：

数据库2：

SQL> select dbtimezone from dual;

DBTIMEZONE

——————

+00:00

SQL> select sessiontimezone from dual;

SESSIONTIMEZONE

——————————————————————————–

+08:00

我们尝试导入刚才在数据库1里导出的表t2：

oracle:/nbsdata01/oradata/testdb>imp \’sys/oracle@testdb as sysdba\’ file=t2.dmp tables=t2 ignore=true

Import: Release 11.2.0.1.0 – Production on Wed Feb 1 17:16:50 2012

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 – 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

Export file created by EXPORT:V11.02.00 via conventional path

import done in UTF8 character set and AL16UTF16 NCHAR character set

import server uses ZHS16GBK character set (possible charset conversion)

. importing SYS’s objects into SYS

. . importing table “T2″ 2 rows imported

Import terminated successfully without warnings.

现在我们来看一下导入的结果：

SQL> select col1,dump(col1) from t2;

COL1

—————————————————————————

DUMP(COL1)

——————————————————————————–

01-FEB-12 04.18.58.839122 PM Typ=231 Len=11: 120,112,2,1,9,19,59,50,3,252,80

02-FEB-12 08.38.19.000000 AM Typ=231 Len=7: 120,112,2,2,1,39,20

现在我们再次回到数据库1并将sessiontimezone设成和数据库2一样：

数据库1：

SQL> ALTER SESSION SET TIME_ZONE = ‘+08:00′;

Session altered

SQL> select col1,dump(col1) from t2;

COL1 DUMP(COL1)

————————————————– ——————————————————————————–

01-2月 -12 04.18.58.839122 下午 Typ=231 Len=11: 120,112,2,1,17,19,59,50,3,252,80

02-2月 -12 08.38.19.000000 上午 Typ=231 Len=7: 120,112,2,2,9,39,20

可以看到两条记录的显示时间是一致的，所以对于timestamp with local time zone而言，数据迁移时不同的时区是没有关系的。

这里的本质原因是Oracle在做数据迁移时，对timestamp with local time zone类型的数据Oracle会根据源库和目标库不同的dbtimezone来对timestamp with local time zone类型的数据做转换。这里数据库1的dbtimezone是+08:00，数据库2的dbtimezone是+00:00，所以Oracle对原来的第一条记录的小时17减了8变成了9,第二条记录的小时9减了8变成1。

Oracle里未成功commit的数据我们也可能能看到

Cui Hua — Sat, 28 Jan 2012 12:47:25 +0000

我们大家都知道的一个常识是——Oracle里未commit的数据除了当前session之外，其他session是看不到的。

我这里演示了一个有趣的例子，在这个例子里我们可以看到，Oracle里未成功commit的数据我们也可能能看到。

我同时启4个session。

先在session 1里创建一个表t1，插入一条数据但不commit：

Session 1:

Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.1.0

Connected as scott

SQL> create table t1(id number, name varchar2(10));

Table created

SQL> insert into t1 values(1,’CUIHUA’);

1 row inserted

SQL> select * from t1;

ID NAME

———- ———-

1 CUIHUA

此时跳到session 2，因session 1里刚插入的那条数据还未commit，所以这个时候session 2是看不到这条数据的：

Session 2:

SQL> select * from t1;

ID NAME

———- ———-

接着我们跳到session 3，把lgwr进程suspend住：

Session 3:

SQL> select spid from v$process where pname=’LGWR’;

SPID

————————

2316

SQL> oradebug setospid 2316

Oracle pid: 11, Windows thread id: 2316, image: ORACLE.EXE (LGWR)

SQL> oradebug suspend

已处理的语句

现在我们回到session 1，执行commit命令，因为lgwr进程已经被我们suspend住了，所以当前session 1里要执行的commit操作一定会被hang住：

Session1：

SQL> commit;

……这里hang住了

Oracle里commit操作的流程是这样的：

1、Oracle先去改这个transaction所对应的undo segment header中slot的状态；

2、改完状态后再flush log buffer；

现在我们把lgwr hold住了，所以上述步骤2 Oracle是没法做了，但步骤1还是可以做的。而只要步骤1做完了，其他的session就能看到这个transaction所做的改变了（通过ITL中记录的transaction id去check相应的undo segment header中slot的状态），也就是说对于其他session而言，这个transaction已经commit了，虽然这个transaction其实并没有成功commit。

好了，我们现在回到session 2，看一下我们现在能否看到刚才insert的那条记录：

Session 2：

SQL> select * from t1;

ID NAME

———- ———-

1 CUIHUA

从结果里可以看到，刚才看不到的那条记录现在我们已经能看到了，即session 1对于session2而言已经commit了，虽然session1的commit操作其实并没有成功的做完。

现在我们跳到session 4，执行shutdown abort：

Session 4：

SQL> shutdown abort

ORACLE 例程已经关闭。

然后我们再在session 4中执行startup，startup后我们从alert log里可以很明显的看到Oracle做了instance recovery：

Sat Jan 28 19:14:03 2012

alter database mount exclusive

Successful mount of redo thread 1, with mount id 4288810811

Database mounted in Exclusive Mode

Lost write protection disabled

Completed: alter database mount exclusive

alter database open

Beginning crash recovery of 1 threads

parallel recovery started with 2 processes

Started redo scan

Completed redo scan

read 918 KB redo, 126 data blocks need recovery

Started redo application at

Thread 1: logseq 44, block 77312

Recovery of Online Redo Log: Thread 1 Group 2 Seq 44 Reading mem 0

Mem# 0: C:\APP\CUIHUA\ORADATA\CUIHUA112\REDO02.LOG

Completed redo application of 0.52MB

Completed crash recovery at

Thread 1: logseq 44, block 79149, scn 1652578

126 data blocks read, 95 data blocks written, 918 redo k-bytes read

等待上述库成功startup后，我们再次回到session 1，看一下刚才我们已经commit的那条数据是否还在：

Session 1：

SQL> select * from t1;

ID NAME

———- ———-

从结果里可以看到，刚才我们insert且执行了commit操作的那条记录现在已经丢失了。