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

研究了几天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竞争案例的更多相关文章

关于shared pool的深入探讨(二)【转载】
关于shared pool的深入探讨(二) 作者:eygle |English [转载时请标明出处和作者信息]|[恩墨学院 OCM培训传DBA成功之道]链接:http://www.eygle.co ...
关于shared pool的深入探讨(一) 【转载】
关于shared pool的深入探讨(一) 作者:eygle |English [转载时请标明出处和作者信息]|[恩墨学院 OCM培训传DBA成功之道]链接:http://www.eygle.co ...
关于shared pool的深入探讨(五)
Oracle使用两种数据结构来进行shared pool的并发控制:lock 和 pin.Lock比pin具有更高的级别. Lock在handle上获得,在pin一个对象之前,必须首先获得该handl ...
关于shared pool的深入探讨(四)
我们进一步来讨论一下shared pool的处理: 先进行相应查询,获得测试数据: [oracle@jumper udump]$ sqlplus "/ as sysdba" SQL ...
关于shared pool的深入探讨(三)
基本命令: ALTER SESSION SET EVENTS 'immediate trace name LIBRARY_CACHE level LL'; 其中LL代表Level级别,对于9.2.0及 ...
[转载】——故障排除：Shared Pool优化和Library Cache Latch冲突优化 (文档 ID 1523934.1)
原文链接:https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrlstate=23w4l35u5_4&id=152393 ...
Oracle Shared Pool 原理
Oracle Shared Pool 原理由于shared pool中最重要的是library cache,所以本文主要讲解Library cache的结构,library cache latch, ...
Oracle数据库大量library cache: mutex X及latch: shared pool问题排查一例
业务系统数据库夯住,数据库内大量的library cache: mutex X及latch: shared pool等待,alert日志信息如下 Tue Sep :: WARNING: inbound ...
Shared pool
Shared pool 一.Shared pool的引入当你发出一条sql语句交付Oracle,在执行和获取结果前,Oracle对此sql将进行几个步骤的处理过程: 1.语法检查(syntax ch ...

随机推荐

linux学习笔记26--命令wc
Linux系统中的wc(Word Count)命令的功能为统计指定文件中的行数.字数.字节数,并将统计结果显示输出. 1．命令格式: wc [选项]文件... 2．命令功能: 统计指定文件中的行数.字 ...
Ubuntu安装新版本nodejs的5种姿势
引言: 写这篇文章之前,关于ubuntu14.04(Trusty)默认安装的NodeJS版本是0.10.25百思不解(什么鬼,哪一年的NodeJS) 写这篇文章之时,NodeJS的LTS版本号都已经1 ...
flutter table 在showModalBottomSheet中
问题是,不知道为什么又可以了.原来是显示黑屏,没有输出. showModalBottomSheet<void>( context: context, builder: (BuildCont ...
换个角度剖析iptables防火墙
这篇文章会尽量以通俗易懂的方式描述iptables的相关概念,请耐心的读完它. 防火墙相关概念此处先描述一些相关概念. 从逻辑上讲.防火墙可以大体分为主机防火墙和网络防火墙. 主机防火墙:针对于单个 ...
哈希表类Hashtable
哈希表是一种重要的存储方式,也是一种常见的检索方法.其基本思想是将关系码的值作为自变量,通过一定的函数关系计算出对应的函数值,把这个数值解释为结点的存储地址,将结点存入计算得到存储地址所对应的存储单元 ...
json DateTime转换
前台: function ChangeDateFormat(jsondate) { jsondate = jsondate.replace("/Date(", "&quo ...
一行代码解决各种IE兼容问题,IE6,IE7,IE8,IE9,IE10 （转）
x-ua-compatible 用来指定IE浏览器解析编译页面的model x-ua-compatible 头标签大小写不敏感,必须用在 head 中,必须在除 title 外的其他 meta 之前使 ...
db2 clob dbclob
DB2有三种类型的大字段: clob(Character Large OBjects ) 适用于存放单字节的字符串,当我们要保存的字符长度超过varchar的最大长度(32K)时,我们就要考虑使用cl ...
非阻塞IO 和阻塞IO【转】
IO模式设置网络编程常见问题总结—IO模式设置,阻塞与非阻塞的比较,recv参数对性能的影响—O_NONBLOCK(open使用).IPC_NOWAIT(msgrcv).MSG_DONTWAIT(re ...
Django model 改成中文标题
class Tag(models.Model): title = models.CharField(max_length=30) def __str__(self): return self.titl ...

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

关于shared pool的深入探讨(六)-高Latch竞争案例的更多相关文章

随机推荐

热门专题