关于shared pool的深入探讨(六)-高Latch竞争案例

原创 eygle 2004-10-31

694

研究了几天shared pool,没想到忽然就撞到问题上来了.
作为一个案例写出来给大家参考一下吧.

问题起因是公司做短信群发,就是那个18万买的4000字的短信小说(嘘,小声点,我也没看过...).
群发的时候每隔一段时间就会发生一次消息队列拥堵的情况
在数据库内部实际上是向一个数据表中记录发送日志.

我们介入来检查数据库的问题,在一个拥堵时段我开始诊断:


SQL> select sid,event,p1,p1raw from v$session_wait;   
       SID EVENT                                                                    P1 P1RAW
---------- ---------------------------------------------------------------- ---------- --------
        76 latch free                                                       2147535824 8000CBD0
        83 latch free                                                       2147535824 8000CBD0
       148 latch free                                                       3415346832 CB920E90
       288 latch free                                                       2147535824 8000CBD0
       285 latch free                                                       2147535824 8000CBD0
       196 latch free                                                       2147535824 8000CBD0
       317 latch free                                                       2147535824 8000CBD0
         2 pmon timer                                                              300 0000012C
         1 rdbms ipc message                                                       300 0000012C
         4 rdbms ipc message                                                       300 0000012C
         6 rdbms ipc message                                                    180000 0002BF20
       SID EVENT                                                                    P1 P1RAW
---------- ---------------------------------------------------------------- ---------- --------
        18 rdbms ipc message                                                      6000 00001770
       102 rdbms ipc message                                                      6000 00001770
       311 rdbms ipc message                                                      6000 00001770
       194 rdbms ipc message                                                      6000 00001770
       178 rdbms ipc message                                                      6000 00001770
         3 log file parallel write                                                   1 00000001
        13 log file sync                                                          2705 00000A91
        16 log file sync                                                          2699 00000A8B
       104 log file sync                                                          2699 00000A8B
       308 log file sync                                                          2694 00000A86
       262 log file sync                                                          2705 00000A91
       SID EVENT                                                                    P1 P1RAW
---------- ---------------------------------------------------------------- ---------- --------
       172 log file sync                                                          2689 00000A81
       169 log file sync                                                          2705 00000A91
       108 log file sync                                                          2694 00000A86
        38 log file sync                                                          2707 00000A93
        34 db file scattered read                                                   63 0000003F
         5 smon timer                                                              300 0000012C
        27 SQL*Net message to client                                        1413697536 54435000
        60 SQL*Net message to client                                        1413697536 54435000
       239 SQL*Net message to client                                        1413697536 54435000
...ignore some idle waiting here...
        11 SQL*Net message from client                                       675562835 28444553
        12 SQL*Net message from client                                      1413697536 54435000
170 rows selected.

在这次查询中,我发现大量的latch free等待,再次查询时这些等待消失,应用也恢复了正常.

 
SQL> select sid,event,p1,p1raw from v$session_wait where event not like 'SQL*Net%';
       SID EVENT                                                                    P1 P1RAW
---------- ---------------------------------------------------------------- ---------- --------
         2 pmon timer                                                              300 0000012C
         1 rdbms ipc message                                                       300 0000012C
         4 rdbms ipc message                                                       300 0000012C
         6 rdbms ipc message                                                    180000 0002BF20
        18 rdbms ipc message                                                      6000 00001770
       102 rdbms ipc message                                                      6000 00001770
       178 rdbms ipc message                                                      6000 00001770
       194 rdbms ipc message                                                      6000 00001770
       311 rdbms ipc message                                                      6000 00001770
         3 log file parallel write                                                   1 00000001
       148 log file sync                                                          2547 000009F3
       SID EVENT                                                                    P1 P1RAW
---------- ---------------------------------------------------------------- ---------- --------
       273 log file sync                                                          2544 000009F0
       190 log file sync                                                          2545 000009F1
         5 smon timer                                                              300 0000012C
14 rows selected.

接下来我们来看这些latch free等待的是哪些latch

 
SQL> select addr,latch#,name,gets,spin_gets from v$latch order by spin_gets;
ADDR         LATCH# NAME                                                                   GETS  SPIN_GETS
-------- ---------- ---------------------------------------------------------------- ---------- ----------
80001398          3 session switching                                                    111937          0
80002010          6 longop free list                                                      37214          0
800023A0          7 cached attr list                                                          0          0
80002628         10 event group latch                                                   2391668          0
.....
80003F3C         28 message pool operations parent latch                                      3          0
.....
80006030         60 mostly latch-free SCN                                                    19          0
80005F8C         59 file number translation table                                            68          0
80005F14         58 dlm cr bast queue latch                                                   0          0
80005E8C         57 name-service request                                                      0          0
80005E14         56 name-service memory objects                                               0          0
80005DA0         55 name-service namespace bucket                                             0          0
ADDR         LATCH# NAME                                                                   GETS  SPIN_GETS
-------- ---------- ---------------------------------------------------------------- ---------- ----------
80005D2C         54 name-service pending queue                                                0          0
80005CB4         53 name-service request queue                                                0          0
80004E08         52 name-service entry                                                        0          0
80008AB0         76 KCL lock element parent latch                                             0          0
80008A48         75 KCL instance latch                                                        0          0
80007F18         73 redo copy                                                               816          0
80007BBC         71 archive process latch                                                     0          0
80007B54         70 archive control                                                           1          0
80006A10         68 Active checkpoint queue latch                                       2003308          0
800064B0         66 large memory latch                                                        0          0
80006448         65 cache protection latch                                                    0          0
ADDR         LATCH# NAME                                                                   GETS  SPIN_GETS
-------- ---------- ---------------------------------------------------------------- ---------- ----------
800060EC         61 batching SCNs                                                             0          0
8000CAB0         96 global transaction                                                  6833807          0
8000CA48         95 global tx free list                                                   58258          0
8000C238         93 cost function                                                             0          0
80009FCC         91 temp lob duration state obj allocation                                    0          0
8000995C         87 ktm global data                                                        8118          0
80009228         84 transaction branch allocation                                        282388          0
80008EC4         80 begin backup scn array                                                 6968          0
80008D54         79 loader state object freelist                                          42712          0
80008B80         78 KCL freelist latch                                                        0          0
80008B18         77 KCL name table latch                                                      0          0
ADDR         LATCH# NAME                                                                   GETS  SPIN_GETS
-------- ---------- ---------------------------------------------------------------- ---------- ----------
8000D484        118 presentation list                                                         0          0
8000D41C        117 session timer                                                        855944          0
.....
8000E9D0        129 process queue                                                            44          0
8000E900        127 query server freelists                                                   66          0
8000FC84        140 AQ Propagation Scheduling System Load                                     0          0
8000E898        126 query server process                                                     10          0
8000E27C        125 job_queue_processes parameter latch                                  111937          0
8000DA1C        124 NLS data objects                                                          2          0
ADDR         LATCH# NAME                                                                   GETS  SPIN_GETS
-------- ---------- ---------------------------------------------------------------- ---------- ----------
8000D95C        123 ncodef allocation latch                                              111937          0
8000D674        122 virtual circuits                                                          0          0
8000D60C        121 virtual circuit queues                                               159877          0
8000D5A4        120 virtual circuit buffers                                                   0          0
8000D4EC        119 address list                                                              2          0
.....
8000CD70        102 Direct I/O Adaptor                                                        2          0
.....
80002408          8 GDS latch                                                                30          0
800092E4         85 sort extent pool                                                      69834          1
8000EC38        132 parallel query alloc buffer                                              80          1
8000E968        128 error message lists                                                      22          1
80001400          4 process group creation                                              2615542          2
8000EAA0        131 parallel query stats                                                     14          2
ADDR         LATCH# NAME                                                                   GETS  SPIN_GETS
-------- ---------- ---------------------------------------------------------------- ---------- ----------
8000CD08        101 Token Manager                                                       1151107          2
8000CB18         97 global tx hash mapping                                               507846          2
80006378         63 cache buffer handles                                                 315924          4
8000EA38        130 process queue reference                                              190993          5
80003E3C         26 channel handle pool latch                                           2391680         18
80003EAC         27 channel operations parent latch                                     4783425         24
80009B90         89 intra txn parallel recovery                                           32654         33
8000FCF8        141 fixed table rows for x$hs_session                                    161368         41
800012C8          1 process allocation                                                  2391688        154
80009B28         88 parallel txn reco latch                                              174519        271
8000CCA0        100 library cache load lock                                            14947545       5958
ADDR         LATCH# NAME                                                                   GETS  SPIN_GETS
-------- ---------- ---------------------------------------------------------------- ---------- ----------
8000C8D0         94 user lock                                                          13086412       6078
8000914C         82 list of block allocation                                          120650357      12024
80006A78         69 Checkpoint queue latch                                            154361751      17686
80009D34         90 sequence cache                                                     64611720      32027
80009090         81 dml lock allocation                                               234465024      45351
800091C0         83 transaction allocation                                            214227648      48345
800096AC         86 undo global data                                                  188271244      49641
800028A0         13 enqueue hash chains                                               373244264     131322
80007E04         72 redo allocation                                                   439389808     201498
80001468          5 session idle bit                                                 2039097976     204969
80002838         12 enqueues                                                          471338482     273695
ADDR         LATCH# NAME                                                                   GETS  SPIN_GETS
-------- ---------- ---------------------------------------------------------------- ---------- ----------
80001330          2 session allocation                                                261826230     428312
800063E0         64 multiblock read objects                                          1380614923    1366278
800026B8         11 messages                                                          207935758    1372606
80001218          0 latch wait list                                                   203479569    1445342
80006310         62 cache buffers chains                                             3.8472E+10    2521699
8000A17C         92 row cache objects                                                1257586714    2555872
80007F80         74 redo writing                                                      264722932    4458044
80006700         67 cache buffers lru chain                                          5664313769   30046921
8000CBD0         98 shared pool                                                       122433688   59070585
8000CC38         99 library cache                                                    4414533796 1037032730
142 rows selected.
SQL> select startup_time from v$instance;
STARTUP_T
---------
13-AUG-04
检查数据库启动时间

我们注意到,在当前数据库中竞争最严重的两个latch是shared pool和library cache.
显然这极有可能是SQL的过度解析造成的.

进一步我们检查v$sqlarea发现:

 
SQL> select sql_text,VERSION_COUNT,INVALIDATIONS,PARSE_CALLS,OPTIMIZER_MODE,
PARSING_USER_ID,PARSING_SCHEMA_ID,ADDRESS,HASH_VALUE
  2  from v$sqlarea where version_count >1000;
SQL_TEXT
------------------------------------------------------------------------------------------------------------------------
VERSION_COUNT INVALIDATIONS PARSE_CALLS OPTIMIZER_MODE            PARSING_USER_ID PARSING_SCHEMA_ID ADDRESS  HASH_VALUE
------------- ------------- ----------- ------------------------- --------------- ----------------- -------- ----------
insert into sms_log (MSGDATE,MSGTIME,MSGID,MSGKIND,MSGTYPE,MSGTYPE_MOMT,MSGLEN,MSGSTATUS,AREAID,IFIDDEST,IFIDSRC,ADDRSRC
,ADDRDEST,ADDRFEE,ADDRUSER,SERVICECODE,PLANID,FEETYPE,FEEVALUE,DATACODING,FLAGS,SMLEN,SMCONT) values (:b0,:b1,:b2,:b3,:b
4,:b5,:b6,:b7,:b8,:b9,:b10,:b11,:b12,:b13,:b14,:b15,:b16,:b17,:b18,:b19,:b20,:b21,:b22)
         7023             0        1596 MULTIPLE CHILDREN PRESENT              36                36 C82AF1C8 3974744754

这就是写日志记录的代码,这段代码使用了绑定变量,但是version_count却有7023个.
也就是这个sql有7023个子指针.这是不可想象的.

通过前面几节的研究我们知道,如果这个sql有7023个子指针
那么意味着这些子指针都将存在于同一个Bucket的链表上
那么这也就意味着,如果同样SQL再次执行,Oracle将不得不搜索这个链表以寻找可以共享的SQL.
这将导致大量的library cache latch的竞争.

这时候我开始猜测原因:
1.可能代码存在问题,在每次执行之前程序修改某些session参数,导致sql不能共性
2.可能是8.1.5的v$sqlarea记录存在问题,我们看到的结果是假象:)
3.Bug

Ok,我们的诊断不能停.
最直接的我dump内存来看:

SQL> ALTER SESSION SET EVENTS 'immediate trace name LIBRARY_CACHE level 4';

察看trace文件得到如下结果(摘录包含该段代码的片断):

 
BUCKET 21049:
  LIBRARY OBJECT HANDLE: handle=c82af1c8
  name=
insert into sms_log (MSGDATE,MSGTIME,MSGID,MSGKIND,MSGTYPE,MSGTYPE_MOMT,MSGLEN,MSGSTATUS,AREAID,IFIDDEST,IFIDSRC,
ADDRSRC,ADDRDEST,ADDRFEE,ADDRUSER,SERVICECODE,PLANID,FEETYPE,FEEVALUE,DATACODING,FLAGS,SMLEN,SMCONT) values 
(:b0,:b1,:b2,:b3,:b4,:b5,:b6,:b7,:b8,:b9,:b10,:b11,:b12,:b13,:b14,:b15,:b16,:b17,:b18,:b19,:b20,:b21,:b22)
  hash=ece9cab2 timestamp=09-09-2004 12:51:29
  namespace=CRSR flags=RON/TIM/PN0/LRG/[10010001]
  kkkk-dddd-llll=0000-0001-0001 lock=N pin=S latch=5
  lwt=c82af1e0[c82af1e0,c82af1e0] ltm=c82af1e8[c82af1e8,c82af1e8]
  pwt=c82af1f8[c82af1f8,c82af1f8] ptm=c82af250[c82af250,c82af250]
  ref=c82af1d0[c82af1d0,c82af1d0]
    LIBRARY OBJECT: object=c1588e84
    type=CRSR flags=EXS[0001] pflags= [00] status=VALD load=0
    CHILDREN: size=7024
    child#    table reference   handle
    ------ -------- --------- --------
         0 c1589040  c1589008 c668c2bc
         1 c1589040  bfd179c4 c6ec9ee8
         2 c1589040  bfd179e0 c2dd9b3c
         3 c1589040  bfd179fc c5a46614
         4 c1589040  bfd17a18 c35f1388
         5 c1589040  bfd17a34 c77401bc
         6 c1589040  bfd17a50 c4092838
         7 c1589040  bfddb310 c6cd5258
         8 c1589040  bfddb32c c63c6650
         9 c1589040  bfddb348 c7e4e3d0
        10 c1589040  bfddb364 c4c4b110
        11 c1589040  bfddb380 c5950348
        12 c1589040  bfddb39c c6c33aa4
        13 c1589040  bfddb3b8 c672b0bc
...........................................        
.....ignore losts of child cursor here.....
...........................................
      7001 bf595bc8  c641fba0 c6467890
      7002 bf595bc8  c641fbbc c3417168
      7003 bf595bc8  c641fbd8 c3417bb0
      7004 bf595bc8  c641fbf4 c2fdccbc
      7005 bf595bc8  c641fc10 c7f7ca50
      7006 bf595bc8  c641fc2c c7f508ec
      7007 bf595bc8  c641fc48 c268d8d8
      7008 c641fcb8  c641fc64 bec61ed8
      7009 c641fcb8  c641fc80 c4a6cc5c
      7010 c641fcb8  c641fc9c c1a8aa34
      7011 c641fcb8  c0ae4ea0 c0ae4ddc
      7012 c641fcb8  c0ae4ebc bd55fe60
      7013 c641fcb8  c0ae4ed8 c226914c
      7014 c641fcb8  c0ae4ef4 c51dd2e0
      7015 c641fcb8  c0ae4f10 c480c468
      7016 c641fcb8  c0ae4f2c c60196d0
      7017 c641fcb8  c0ae4f48 c4675d2c
      7018 c641fcb8  c0ae4f64 bd5e2750
      7019 c641fcb8  c0ae4f80 c09b1bb0
      7020 c641fcb8  c0ae4f9c bf2d6044
      7021 c641fcb8  c0ae4fb8 c332c1c4
      7022 c641fcb8  c0ae4fd4 cbdde0f8
    DATA BLOCKS:
    data#     heap  pointer status pins change
    ----- -------- -------- ------ ---- ------
        0 c3ef2c50 c1588f08 I/P/A     0 NONE

这里确实存在7023个子指针

查询v$sql得到相同的结果:

 
SQL> select CHILD_NUMBER,EXECUTIONS,OPTIMIZER_MODE,OPTIMIZER_COST,PARSING_USER_ID,PARSING_SCHEMA_ID,ADDRESS,HASH_VALUE  
   2 from v$sql where HASH_VALUE='3974744754';    
CHILD_NUMBER EXECUTIONS OPTIMIZER_ OPTIMIZER_COST PARSING_USER_ID PARSING_SCHEMA_ID ADDRESS  HASH_VALUE
------------ ---------- ---------- -------------- --------------- ----------------- -------- ----------
           0      12966 CHOOSE             238150              36                36 C82AF1C8 3974744754
           1       7111 CHOOSE             238150              36                36 C82AF1C8 3974744754
           2       9160 CHOOSE             238150              36                36 C82AF1C8 3974744754
           3       9127 CHOOSE             238150              36                36 C82AF1C8 3974744754
           4       8109 CHOOSE             238150              36                36 C82AF1C8 3974744754
           5       4386 CHOOSE             238150              36                36 C82AF1C8 3974744754
           6       4913 CHOOSE             238150              36                36 C82AF1C8 3974744754
           7       3764 CHOOSE             238150              36                36 C82AF1C8 3974744754
           8       3287 CHOOSE             238150              36                36 C82AF1C8 3974744754
           9       3156 CHOOSE             238150              36                36 C82AF1C8 3974744754
.....
        7015          1 CHOOSE             238150              36                36 C82AF1C8 3974744754
        7016          1 CHOOSE             238150              36                36 C82AF1C8 3974744754
        7017          0 CHOOSE             238150              36                36 C82AF1C8 3974744754
CHILD_NUMBER EXECUTIONS OPTIMIZER_ OPTIMIZER_COST PARSING_USER_ID PARSING_SCHEMA_ID ADDRESS  HASH_VALUE
------------ ---------- ---------- -------------- --------------- ----------------- -------- ----------
        7018       9396 NONE                                    0                 0 C82AF1C8 3974744754
        7019       5008 CHOOSE             237913              36                36 C82AF1C8 3974744754
        7020        625 CHOOSE             237913              36                36 C82AF1C8 3974744754
        7021      10101 CHOOSE             237913              36                36 C82AF1C8 3974744754
        7022       7859 CHOOSE             237913              36                36 C82AF1C8 3974744754
7023 rows selected.

这里确实存在7023个子指针,第二种猜测被否定了,同时研发发过来的代码也不存在第一种情况.
那么只能是第三种情况了,Oracle的Bug,Ok,那我们需要找到解决办法.

搜索Metalink,发现Bug:1210242
该Bug描述为:
On certain SQL statements cursors are not shared when TIMED_STATISTICS is enabled.

碰巧我这个数据库的TIMED_STATISTICS设置为True
修改TIMED_STATISTICS为False以后,观察v$sql,发现有效子指针很快下降到2个.

 
SQL> select CHILD_NUMBER,OPTIMIZER_COST,OPTIMIZER_MODE,EXECUTIONS,ADDRESS 
        from v$sql where hash_value=3974744754 and OPTIMIZER_MODE='CHOOSE';
CHILD_NUMBER OPTIMIZER_COST OPTIMIZER_ EXECUTIONS ADDRESS
------------ -------------- ---------- ---------- --------
           0         238167 CHOOSE          63943 C82AF1C8
           1         238300 CHOOSE          28915 C82AF1C8

第二天下降到只有一个.

 
SQL> select CHILD_NUMBER,OPTIMIZER_COST,OPTIMIZER_MODE,EXECUTIONS,ADDRESS 
        from v$sql where hash_value=3974744754 and OPTIMIZER_MODE='CHOOSE';
CHILD_NUMBER OPTIMIZER_COST OPTIMIZER_ EXECUTIONS ADDRESS
------------ -------------- ---------- ---------- --------
           0         238702 CHOOSE         578124 C82AF1C8

短信群发从此正常.

对于这个问题,另外一个可选的方法是设置一个隐含参数:
_sqlexec_progression_cost = 0

这个参数的具体含义为:
SQL execution progression monitoring cost threshold
即:SQL执行进度监控成本阀值

这个参数根据COST来决定需要监控的SQL.执行进度监控会引入额外的函数调用和Row Sources
这可能导致SQL的执行计划或成本发生改变,从而产生不同的子指针.
_sqlexec_progression_cost 的缺省值为1000,成本大于1000的所有SQL都会被监控
如果该参数设置为0,那么SQL的执行进度将不会被跟踪.

执行进度监控信息会被记录到V$SESSION_LONGOPS视图中,如果Time_statistics参数设置为False,那么这个信息就不会被记录.

所以,Time_statistics参数和_sqlexec_progression_cost是解决问题的两个途径.

通过查询我们也可以看到,在这个数据库中,OPTIMIZER_COST >1000的SQL主要有以下五个:

 
SQL> select distinct(sql_text) from v$sql where OPTIMIZER_COST >1000;
SQL_TEXT
--------------------------------------------------------------------------------
insert into sms_detail_error (msgdate,addruser,msgid,areaid,reason,spnumber,msgt
ime,ifiddest,msqkey,servicecode,planid,feetype,feevalue,smcont,submittimes,submi
tdate,submittime,msgstate_resp,errorcode_resp,msgstate_rept,errorcode_rept) valu
es (:b0,:b1,:b2,:b3,:b4,:b5,:b6,:b7,:b8,:b9,:b10,:b11,:b12,:b13,:b14,:b15,:b16,:
b17,:b18,:b19,:b20)
insert into sms_detail_success (msgdate,addruser,msgid,areaid,spnumber,msgtime,i
fiddest,servicecode,planid,feetype,feevalue,smcont,submittimes,submitdate,submit
time,respdate,resptime,reptdate,repttime,msqkey) values (:b0,:b1,:b2,:b3,:b4,:b5
,:b6,:b7,:b8,:b9,:b10,:b11,:b12,:b13,:b14,:b15,:b16,:b17,:b18,:b19)
insert into sms_log (MSGDATE,MSGTIME,MSGID,MSGKIND,MSGTYPE,MSGTYPE_MOMT,MSGLEN,M
SGSTATUS,AREAID,IFIDDEST,IFIDSRC,ADDRSRC,ADDRDEST,ADDRFEE,ADDRUSER,SERVICECODE,P
LANID,FEETYPE,FEEVALUE,DATACODING,FLAGS,SMLEN,SMCONT) values (:b0,:b1,:b2,:b3,:b
4,:b5,:b6,:b7,:b8,:b9,:b10,:b11,:b12,:b13,:b14,:b15,:b16,:b17,:b18,:b19,:b20,:b2
1,:b22)
insert into sms_resprept_error (msgdate,areaid,addruser,msgid,submittimes,submit
date,submittime,msgid_gw,msgstate_resp,errorcode_resp,msgstate_rept,errorcode_re
pt,servicecode) values (:b0,:b1,:b2,:b3,:b4,:b5,:b6,:b7,:b8,:b9,:b10,:b11,:b12)
insert into sms_statusrept (reptdate,addruser,msgid_gw,repttime,statustype,msgid
_stus,msgstate,errorcode) values (:b0,:b1,:b2,:b3,:b4,:b5,:b6,:b7)

而这五个SQL中,在v$sqlarea中,有四个version_count都在10以上:

 
SQL>  select sql_text,version_count from v$sqlarea where version_count>10;
SQL_TEXT
--------------------------------------------------------------------------------
VERSION_COUNT
-------------
insert into sms_detail_error (msgdate,addruser,msgid,areaid,reason,spnumber,msgt
ime,ifiddest,msqkey,servicecode,planid,feetype,feevalue,smcont,submittimes,submi
tdate,submittime,msgstate_resp,errorcode_resp,msgstate_rept,errorcode_rept) valu
es (:b0,:b1,:b2,:b3,:b4,:b5,:b6,:b7,:b8,:b9,:b10,:b11,:b12,:b13,:b14,:b15,:b16,:
b17,:b18,:b19,:b20)
           42
insert into sms_log (MSGDATE,MSGTIME,MSGID,MSGKIND,MSGTYPE,MSGTYPE_MOMT,MSGLEN,M
SGSTATUS,AREAID,IFIDDEST,IFIDSRC,ADDRSRC,ADDRDEST,ADDRFEE,ADDRUSER,SERVICECODE,P
LANID,FEETYPE,FEEVALUE,DATACODING,FLAGS,SMLEN,SMCONT) values (:b0,:b1,:b2,:b3,:b
4,:b5,:b6,:b7,:b8,:b9,:b10,:b11,:b12,:b13,:b14,:b15,:b16,:b17,:b18,:b19,:b20,:b2
1,:b22)
         7026
insert into sms_resprept_error (msgdate,areaid,addruser,msgid,submittimes,submit
date,submittime,msgid_gw,msgstate_resp,errorcode_resp,msgstate_rept,errorcode_re
pt,servicecode) values (:b0,:b1,:b2,:b3,:b4,:b5,:b6,:b7,:b8,:b9,:b10,:b11,:b12)
          301
insert into sms_statusrept (reptdate,addruser,msgid_gw,repttime,statustype,msgid
_stus,msgstate,errorcode) values (:b0,:b1,:b2,:b3,:b4,:b5,:b6,:b7)
           41

具体可以参考Metalink: Note 62143

至此这个关于shared pool的问题找到了原因,并得以及时解决.

<<上一页

「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」

关注作者

关于shared pool的深入探讨(六)-高Latch竞争案例

评论