視圖合併、hash join連接列數據分佈不均勻引發的慘案

来源:http://www.cnblogs.com/pangduzi/archive/2016/08/26/5809142.html
-Advertisement-
Play Games

表大小 慢的sql select a.city, a.agent_id, a.username, a.real_name, phone, zgy_name, login_count, user_count, count(distinct b.invest_id) user_invested, sum ...


表大小

SQL> select count(*) from agent.TB_AGENT_INFO;

  COUNT(*)
----------
      1751

SQL> select count(*) from TB_CHANNEL_INFO ;

  COUNT(*)
----------
      1807

SQL> select count(*) from TB_USER_CHANNEL;

  COUNT(*)
----------
      7269

SQL> select count(*) from OSS_USER_STATION;

  COUNT(*)
----------
      2149

SQL> select count(*) from tb_user_zgy ;

  COUNT(*)
----------
  43

SQL> select count(*) from act.tb_user_agent_relat;

  COUNT(*)
----------
     29612

SQL> select count(*) from agent.base_data_user_info ;

  COUNT(*)
----------
     30005

SQL> select count(*) from agent.base_data_invest_info;

  COUNT(*)
----------
   3530163

慢的sql

select a.city,
       a.agent_id,
       a.username,
       a.real_name,
       phone,
       zgy_name,
       login_count,
       user_count,
       count(distinct b.invest_id) user_invested,
       sum(b.order_amount / 100) invest_amount
  from (select a.city,
               a.agent_id,
               a.username,
               a.real_name, -- 業主姓名
               a.phone, -- 業主手機號
               d.real_name zgy_name, -- 所屬專管員
               count(distinct case
                       when c.str_day <= '20160821' then
                        c.login_name
                     end) login_count,
               count(distinct case
                       when c.str_day <= '20160821' then
                        decode(c.status, 1, c.invest_id, null)
                     end) user_count
          from (select agent_id, city, username, real_name, phone
                   from agent.TB_AGENT_INFO
                  where agent_id in
                        (SELECT agent_id
                           FROM (SELECT distinct *
                                   FROM TB_CHANNEL_INFO t
                                  START WITH t.CHANNEL_ID in
                                             (select CHANNEL_ID
                                                from TB_USER_CHANNEL
                                               where USER_ID = 596)
                                 CONNECT BY PRIOR
                                             t.CHANNEL_ID = t.PARENT_CHANNEL_ID)
                          WHERE agent_id IS NOT NULL)) a
          left join oss_user_station e
            on a.agent_id = e.agent_id
           and e.user_type = 0
          left join tb_user_zgy d
            on e.username = d.username
          left join act.tb_user_agent_relat  c
            on a.agent_id = c.agent_id
         group by a.city,
                  a.username,
                  a.real_name,
                  a.phone,
                  d.real_name,
                  a.agent_id) a
  left join (select invest_id, order_amount, agent_id, str_day
               from agent.base_data_invest_info
              where str_day >= '20150801' and str_day<='20160821') b
    on a.agent_id = b.agent_id
 group by a.city,
          a.agent_id,
          a.username,
          a.real_name,
          a.phone,
          a.zgy_name,
          a.login_count,
          a.user_count
這個查詢可以看成兩部分，第一部分一堆小表關聯的a和唯一的一個大表再做關聯

man
----------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                        | Name                  | Rows  | Bytes |TempSpc| Cost (%CPU)| Time    |
----------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                                 |                       |    55M|  6616M|       |  3934K  (1)| 13:06:52 |
|   1 |  HASH GROUP BY                                   |                       |    55M|  6616M|       |  3934K  (1)| 13:06:52 |
|   2 |   VIEW                                           | VW_DAG_1              |    55M|  6616M|       |  3934K  (1)| 13:06:52 |
|   3 |    HASH GROUP BY                                 |                       |    55M|  6301M|  7681M|  3934K  (1)| 13:06:52 |
|   4 |     VIEW                                         | VM_NWVW_0             |    55M|  6301M|       |  2456K  (1)| 08:11:15 |
|   5 |      SORT GROUP BY                               |                       |    55M|    10G|    11G|  2456K  (1)| 08:11:15 |
|*  6 |       HASH JOIN RIGHT OUTER                      |                       |    55M|    10G|       | 21643   (2)| 00:04:20 |
|   7 |        TABLE ACCESS FULL                         | TB_USER_AGENT_RELAT   | 27937 |  1200K|       |   102   (0)| 00:00:02 |
|*  8 |        HASH JOIN OUTER                           |                       |  3374K|   511M|       | 21392   (1)| 00:04:17 |
|*  9 |         HASH JOIN SEMI                           |                       |  1712 |   188K|       |  2007   (1)| 00:00:25 |
|* 10 |          HASH JOIN RIGHT OUTER                   |                       |  1712 |   173K|       |    32   (0)| 00:00:01 |
|  11 |           TABLE ACCESS FULL                      | TB_USER_ZGY           |    43 |   903 |       |     3   (0)| 00:00:01 |
|* 12 |           HASH JOIN RIGHT OUTER                  |                       |  1712 |   138K|       |    29   (0)| 00:00:01 |
|* 13 |            TABLE ACCESS FULL                     | OSS_USER_STATION      |  1075 | 25800 |       |     6   (0)| 00:00:01 |
|  14 |            TABLE ACCESS FULL                     | TB_AGENT_INFO         |  1712 |    98K|       |    23   (0)| 00:00:01 |
|  15 |          VIEW                                    | VW_NSO_1              | 16271 |   143K|       |  1975   (1)| 00:00:24 |
|* 16 |           VIEW                                   |                       | 16271 |   143K|       |  1975   (1)| 00:00:24 |
|  17 |            HASH UNIQUE                           |                       | 16271 |  8882K|    10M|  1975   (1)| 00:00:24 |
|* 18 |             CONNECT BY WITHOUT FILTERING (UNIQUE)|                       |       |       |       |            |          |
|* 19 |              HASH JOIN RIGHT SEMI                |                       |   530 |   146K|       |    29   (0)| 00:00:01 |
|* 20 |               TABLE ACCESS FULL                  | TB_USER_CHANNEL       |   600 |  7800 |       |     7   (0)| 00:00:01 |
|  21 |               TABLE ACCESS FULL                  | TB_CHANNEL_INFO       |  1807 |   476K|       |    22   (0)| 00:00:01 |
|  22 |              TABLE ACCESS FULL                   | TB_CHANNEL_INFO       |  1807 |   476K|       |    22   (0)| 00:00:01 |
|* 23 |         TABLE ACCESS FULL                        | BASE_DATA_INVEST_INFO |  3374K|   148M|       | 19375   (1)| 00:03:53 |
----------------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   6 - access("AGENT_ID"="C"."AGENT_ID"(+))
   8 - access("AGENT_ID"="AGENT_ID"(+))
   9 - access("AGENT_ID"="AGENT_ID")
  10 - access("C"."USERNAME"="D"."USERNAME"(+))
  12 - access("AGENT_ID"="C"."AGENT_ID"(+))
  13 - filter("C"."USER_TYPE"(+)=0)
  16 - filter("AGENT_ID" IS NOT NULL)
  18 - access("T"."PARENT_CHANNEL_ID"=PRIOR "T"."CHANNEL_ID")
  19 - access("T"."CHANNEL_ID"="CHANNEL_ID")
  20 - filter("USER_ID"=596)
  23 - filter("STR_DAY"(+)>='20150801' AND "STR_DAY"(+)<='20160821')

嘗試單獨跑 a,很快

(select a.city,
               a.agent_id,
               a.username,
               a.real_name, -- 業主姓名
               a.phone, -- 業主手機號
               d.real_name zgy_name, -- 所屬專管員
               count(distinct case
                       when c.str_day <= '20160821' then
                        c.login_name
                     end) login_count,
               count(distinct case
                       when c.str_day <= '20160821' then
                        decode(c.status, 1, c.invest_id, null)
                     end) user_count
          from (select agent_id, city, username, real_name, phone
                   from agent.TB_AGENT_INFO
                  where agent_id in
                        (SELECT agent_id
                           FROM (SELECT distinct *
                                   FROM TB_CHANNEL_INFO t
                                  START WITH t.CHANNEL_ID in
                                             (select CHANNEL_ID
                                                from TB_USER_CHANNEL
                                               where USER_ID = 596)
                                 CONNECT BY PRIOR
                                             t.CHANNEL_ID = t.PARENT_CHANNEL_ID)
                          WHERE agent_id IS NOT NULL)) a
          left join oss_user_station e
            on a.agent_id = e.agent_id
           and e.user_type = 0
          left join tb_user_zgy d
            on e.username = d.username
          left join act.tb_user_agent_relat  c
            on a.agent_id = c.agent_id
         group by a.city,
                  a.username,
                  a.real_name,
                  a.phone,
                  d.real_name,
                  a.agent_id) a

單獨跑a很快，和b合在一起就很慢，那麼懷疑是由於視圖合併，導致了a內部的表提前去和b關聯，引發了性能問題。
嘗試禁止視圖合併可以使用rownum>0,或no_merge hint

select a.city,
       a.agent_id,
       a.username,
       a.real_name,
       phone,
       zgy_name,
       login_count,
       user_count,
       count(distinct b.invest_id) user_invested,
       sum(b.order_amount / 100) invest_amount
  from (select * from (select a.city,
               a.agent_id,
               a.username,
               a.real_name, -- 業主姓名
               a.phone, -- 業主手機號
               d.real_name zgy_name, -- 所屬專管員
               count(distinct case
                       when c.str_day <= '20160821' then
                        c.login_name
                     end) login_count,
               count(distinct case
                       when c.str_day <= '20160821' then
                        decode(c.status, 1, c.invest_id, null)
                     end) user_count
          from (select agent_id, city, username, real_name, phone
                   from agent.TB_AGENT_INFO
                  where agent_id in
                        (SELECT agent_id
                           FROM (SELECT distinct *
                                   FROM TB_CHANNEL_INFO t
                                  START WITH t.CHANNEL_ID in
                                             (select CHANNEL_ID
                                                from TB_USER_CHANNEL
                                               where USER_ID = 596)
                                 CONNECT BY PRIOR
                                             t.CHANNEL_ID = t.PARENT_CHANNEL_ID)
                          WHERE agent_id IS NOT NULL)) a
          left join oss_user_station e
            on a.agent_id = e.agent_id
           and e.user_type = 0
          left join tb_user_zgy d
            on e.username = d.username
          left join act.tb_user_agent_relat  c
            on a.agent_id = c.agent_id
         group by a.city,
                  a.username,
                  a.real_name,
                  a.phone,
                  d.real_name,
                  a.agent_id) where rownum>0)a
  left join (select invest_id, order_amount, agent_id, str_day
               from agent.base_data_invest_info
              where str_day >= '20150801' and str_day<='20160821') b
    on a.agent_id = b.agent_id
 group by a.city,
          a.agent_id,
          a.username,
          a.real_name,
          a.phone,
          a.zgy_name,
          a.login_count,
          a.user_count

kuai
-----------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                         | Name                  | Rows  | Bytes |TempSpc| Cost (%CPU)| Time    |
-----------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                                  |                       |   823M|    96G|       |    23M  (1)| 78:59:52 |
|   1 |  HASH GROUP BY                                    |                       |   823M|    96G|       |    23M  (1)| 78:59:52 |
|   2 |   VIEW                                            | VW_DAG_0              |   823M|    96G|       |    23M  (1)| 78:59:52 |
|   3 |    HASH GROUP BY                                  |                       |   823M|    98G|   112G|    23M  (1)| 78:59:52 |
|*  4 |     HASH JOIN OUTER                               |                       |   823M|    98G|    26M| 41358   (6)| 00:08:17 |
|   5 |      VIEW                                         |                       |   259K|    23M|       | 11090   (1)| 00:02:14 |
|   6 |       COUNT                                       |                       |       |       |       |            |          |
|*  7 |        FILTER                                     |                       |       |       |       |            |          |
|   8 |         VIEW                                      |                       |   259K|    23M|       | 11090   (1)| 00:02:14 |
|   9 |          SORT GROUP BY                            |                       |   259K|    38M|    41M| 11090   (1)| 00:02:14 |
|* 10 |           HASH JOIN                               |                       |   259K|    38M|       |  2111   (1)| 00:00:26 |
|* 11 |            VIEW                                   |                       | 16271 |   143K|       |  1975   (1)| 00:00:24 |
|  12 |             HASH UNIQUE                           |                       | 16271 |  8882K|    10M|  1975   (1)| 00:00:24 |
|* 13 |              CONNECT BY WITHOUT FILTERING (UNIQUE)|                       |       |       |       |            |          |
|* 14 |               HASH JOIN RIGHT SEMI                |                       |   530 |   146K|       |    29   (0)| 00:00:01 |
|* 15 |                TABLE ACCESS FULL                  | TB_USER_CHANNEL       |   600 |  7800 |       |     7   (0)| 00:00:01 |
|  16 |                TABLE ACCESS FULL                  | TB_CHANNEL_INFO       |  1807 |   476K|       |    22   (0)| 00:00:01 |
|  17 |               TABLE ACCESS FULL                   | TB_CHANNEL_INFO       |  1807 |   476K|       |    22   (0)| 00:00:01 |
|* 18 |            HASH JOIN OUTER                        |                       | 27937 |  4037K|       |   134   (0)| 00:00:02 |
|* 19 |             HASH JOIN RIGHT OUTER                 |                       |  1712 |   173K|       |    32   (0)| 00:00:01 |
|  20 |              TABLE ACCESS FULL                    | TB_USER_ZGY           |    43 |   903 |       |     3   (0)| 00:00:01 |
|* 21 |              HASH JOIN RIGHT OUTER                |                       |  1712 |   138K|       |    29   (0)| 00:00:01 |
|* 22 |               TABLE ACCESS FULL                   | OSS_USER_STATION      |  1075 | 25800 |       |     6   (0)| 00:00:01 |
|  23 |               TABLE ACCESS FULL                   | TB_AGENT_INFO         |  1712 |    98K|       |    23   (0)| 00:00:01 |
|  24 |             TABLE ACCESS FULL                     | TB_USER_AGENT_RELAT   | 27937 |  1200K|       |   102   (0)| 00:00:02 |
|* 25 |      TABLE ACCESS FULL                            | BASE_DATA_INVEST_INFO |  3374K|   109M|       | 19375   (1)| 00:03:53 |
-----------------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   4 - access("A"."AGENT_ID"="AGENT_ID"(+))
   7 - filter(ROWNUM>0)
  10 - access("AGENT_ID"="AGENT_ID")
  11 - filter("AGENT_ID" IS NOT NULL)
  13 - access("T"."PARENT_CHANNEL_ID"=PRIOR "T"."CHANNEL_ID")
  14 - access("T"."CHANNEL_ID"="CHANNEL_ID")
  15 - filter("USER_ID"=596)
  18 - access("AGENT_ID"="C"."AGENT_ID"(+))
  19 - access("C"."USERNAME"="D"."USERNAME"(+))
  21 - access("AGENT_ID"="C"."AGENT_ID"(+))
  22 - filter("C"."USER_TYPE"(+)=0)
  25 - filter("STR_DAY"(+)>='20150801' AND "STR_DAY"(+)<='20160821')

用no_merge hint禁止視圖合併也可以

select a.city,
       a.agent_id,
       a.username,
       a.real_name,
       phone,
       zgy_name,
       login_count,
       user_count,
       count(distinct b.invest_id) user_invested,
       sum(b.order_amount / 100) invest_amount
  from (select /*+ no_merge */
               a.city,
               a.agent_id,
               a.username,
               a.real_name, -- 業主姓名
               a.phone, -- 業主手機號
               d.real_name zgy_name, -- 所屬專管員
               count(distinct case
                       when c.str_day <= '20160821' then
                        c.login_name
                     end) login_count,
               count(distinct case
                       when c.str_day <= '20160821' then
                        decode(c.status, 1, c.invest_id, null)
                     end) user_count
          from (select  /*+ qb_name(sb) */ agent_id, city, username, real_name, phone
                   from agent.TB_AGENT_INFO
                  where agent_id in
                        (SELECT agent_id
                           FROM (SELECT distinct *
                                   FROM TB_CHANNEL_INFO t
                                  START WITH t.CHANNEL_ID in
                                             (select CHANNEL_ID
                                                from TB_USER_CHANNEL
                                               where USER_ID = 596)
                                 CONNECT BY PRIOR
                                             t.CHANNEL_ID = t.PARENT_CHANNEL_ID)
                          WHERE agent_id IS NOT NULL)) a
          left join oss_user_station e
            on a.agent_id = e.agent_id
           and e.user_type = 0
          left join tb_user_zgy d
            on e.username = d.username
          left join (select * from act.tb_user_agent_relat c) c
            on a.agent_id = c.agent_id
         group by a.city,
                  a.username,
                  a.real_name,
                  a.phone,
                  d.real_name,
                  a.agent_id) a
  left join (select invest_id, order_amount, agent_id, str_day
               from agent.base_data_invest_info
              where str_day >= '20150801' and str_day<='20160821') b
    on a.agent_id = b.agent_id
 group by a.city,
          a.agent_id,
          a.username,
          a.real_name,
          a.phone,
          a.zgy_name,
          a.login_count,
          a.user_count

至此sql從一個小時都跑不完，到最後兩秒跑完，工作已經完成，但是單從慢的執行計劃中並沒有看出什麼問題。有聚合函數group by走hash沒有錯，雖然有全表掃描帶*但是要麼過濾性太差，要麼不是性能瓶頸。那為什麼總共300多w就跑不完了呢

慢的執行計劃做一個10046

Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max)  Row Source Operation
---------- ---------- ----------  ---------------------------------------------------
         0          0          0  HASH GROUP BY (cr=0 pr=0 pw=0 time=278 us cost=3934270 size=6937507584 card=55059584)
         0          0          0   VIEW  VW_DAG_1 (cr=0 pr=0 pw=0 time=111 us cost=3934270 size=6937507584 card=55059584)
         0          0          0    HASH GROUP BY (cr=0 pr=0 pw=0 time=108 us cost=3934270 size=6607150080 card=55059584)
         0          0          0     VIEW  VM_NWVW_0 (cr=0 pr=0 pw=0 time=32 us cost=2456206 size=6607150080 card=55059584)
         0          0          0      SORT GROUP BY (cr=0 pr=0 pw=0 time=31 us cost=2456206 size=11177095552 card=55059584)
 148234852  148234852  148234852       HASH JOIN RIGHT OUTER (cr=34882 pr=0 pw=0 time=34098445 us cost=21643 size=11177095552 card=55059584)
     29651      29651      29651        TABLE ACCESS FULL TB_USER_AGENT_RELAT (cr=332 pr=0 pw=0 time=8201 us cost=102 size=1229228 card=27937)
    703556     703556     703556        HASH JOIN OUTER (cr=34550 pr=0 pw=0 time=1518631 us cost=21392 size=536480628 card=3374092)
       612        612        612         HASH JOIN SEMI (cr=272 pr=0 pw=0 time=31359 us cost=2007 size=193456 card=1712)
      1751       1751       1751          HASH JOIN RIGHT OUTER (cr=100 pr=0 pw=0 time=11404 us cost=32 size=178048 card=1712)
        43         43         43           TABLE ACCESS FULL TB_USER_ZGY (cr=2 pr=0 pw=0 time=103 us cost=3 size=903 card=43)
      1751       1751       1751           HASH JOIN RIGHT OUTER (cr=98 pr=0 pw=0 time=6664 us cost=29 size=142096 card=1712)
      1312       1312       1312            TABLE ACCESS FULL OSS_USER_STATION (cr=15 pr=0 pw=0 time=420 us cost=6 size=25800 card=1075)
      1751       1751       1751            TABLE ACCESS FULL TB_AGENT_INFO (cr=83 pr=0 pw=0 time=1804 us cost=23 size=101008 card=1712)
       612        612        612          VIEW  VW_NSO_1 (cr=172 pr=0 pw=0 time=19720 us cost=1975 size=146439 card=16271)
       612        612        612           VIEW  (cr=172 pr=0 pw=0 time=19351 us cost=1975 size=146439 card=16271)
       613        613        613            HASH UNIQUE (cr=172 pr=0 pw=0 time=19224 us cost=1975 size=9095489 card=16271)
      1215       1215       1215             CONNECT BY WITHOUT FILTERING (UNIQUE) (cr=172 pr=0 pw=0 time=16687 us)
       603        603        603              HASH JOIN RIGHT SEMI (cr=97 pr=0 pw=0 time=4922 us cost=29 size=149990 card=530)
       603        603        603               TABLE ACCESS FULL TB_USER_CHANNEL (cr=22 pr=0 pw=0 time=550 us cost=7 size=7800 card=600)
      1807       1807       1807               TABLE ACCESS FULL TB_CHANNEL_INFO (cr=75 pr=0 pw=0 time=1615 us cost=22 size=487890 card=1807)
      1807       1807       1807              TABLE ACCESS FULL TB_CHANNEL_INFO (cr=75 pr=0 pw=0 time=1133 us cost=22 size=487890 card=1807)
   1631878    1631878    1631878         TABLE ACCESS FULL BASE_DATA_INVEST_INFO (cr=34278 pr=0 pw=0 time=950767 us cost=19375 size=155208232 card=3374092)

id 6 1億4千多萬，一個多小時也沒跑出來
並且temp撐爆了
第 43 行出現錯誤:
ORA-01652: 無法通過 128 (在表空間 TEMP 中) 擴展 temp 段
一億四千多萬，b表才300萬，sql group by之前也不過一百多萬的結果

根據 6 -
access("AGENT_ID"="C"."AGENT_ID"(+)) 查看c和b表agent_id數據分佈

select agent_id,count(*) from act.tb_user_agent_relat group by agent_id order by 2 desc

最多的6827行，最少的1行

select agent_id,count(*) from agent.base_data_invest_info group by agent_id order by 2 desc

最多50w，最少1行
又一次進了hash join鏈接列數據分佈不均勻的坑，hash join只適合數據分佈均勻的列做鏈接條件

做個oradebug short_stack

SQL> select unique sid from v$mystat;

       SID
----------
      1132

SQL> select p.spid from v$process p ,v$session s where s.paddr=p.addr and s.sid=1132;

SPID
------------------------------------------------
28539
      
oradebug setospid 28539

SQL> oradebug short_stack
ksedsts()+465<-ksdxfstk()+32<-ksdxcb()+1927<-sspuser()+112<-__sighandler()<-io_submit()+7<-skgfqio()+1275<-ksfd_skgfqio()+894<-ksfdgo()+423<-ksfdaio()+2290<-kcflbi()+906<-kcbldio()+3104<-kcblsltio()+530<-stsIssueWrite()+118<-stsGetBlock()+442<-sdbinb()+135<-sdbput()+1042<-smbwrt()+247<-smbput()+2503<-sorput()+93<-qesaEvaAndPutDistAggOpns()+590<-qergsRowP()+430<-qerhjWalkHashBucket()+397<-qerhjGenProbeHashTable()+1571<-qerhjGenProbeHashTable()+718<-kdstf11011010000km()+673<-kdsttgr()+153241<-qertbFetch()+2455<-rwsfcd()+103<-qerhjFetch()+1661<-rwsfcd()+103<-qerhjFetch()+1661<-qergsFetch()+757<-qervwFetch()+139<-qerghFetch()+315<-qervwFetch()+139<-qerghFetch()+315<-opifch2()+2766<-kpoal8()+2833<-opiodr()+917<-ttcpip()+2183<-opitsk()+1710<-opiino()+969<-opiodr()+917<-opidrv()+570<-sou2o()+103<-opimai_real()+133<-ssthrdmain()+265<-main()+201<-__libc_start_main()+244
SQL> 
SQL> 
SQL> 
SQL> 
SQL> oradebug short_stack
ksedsts()+465<-ksdxfstk()+32<-ksdxcb()+1927<-sspuser()+112<-__sighandler()<-io_submit()+7<-skgfqio()+1275<-ksfd_skgfqio()+894<-ksfdgo()+423<-ksfdaio()+2290<-kcflbi()+906<-kcbldio()+3104<-kcblsltio()+530<-stsIssueWrite()+118<-stsGetBlock()+442<-sdbinb()+135<-sdbput()+1042<-smbwrt()+247<-smbput()+2503<-sorput()+93<-qesaEvaAndPutDistAggOpns()+590<-qergsRowP()+430<-qerhjWalkHashBucket()+397<-qerhjGenProbeHashTable()+1571<-qerhjWalkHashBucket()+397<-qerhjGenProbeHashTable()+1571<-kdstf11011010000km()+673<-kdsttgr()+153241<-qertbFetch()+2455<-rwsfcd()+103<-qerhjFetch()+1661<-rwsfcd()+103<-qerhjFetch()+1661<-qergsFetch()+757<-qervwFetch()+139<-qerghFetch()+315<-qervwFetch()+139<-qerghFetch()+315<-opifch2()+2766<-kpoal8()+2833<-opiodr()+917<-ttcpip()+2183<-opitsk()+1710<-opiino()+969<-opiodr()+917<-opidrv()+570<-sou2o()+103<-opimai_real()+133<-ssthrdmain()+265<-main()+201<-__libc_start_main()+244
SQL> 
SQL> 
SQL> 
SQL> 

SQL> oradebug short_stack
ksedsts()+465<-ksdxfstk()+32<-ksdxcb()+1927<-sspuser()+112<-__sighandler()<-qergsRowP()+2161<-qerhjWalkHashBucket()+397<-qerhjGenProbeHashTable()+1571<-qerhjWalkHashBucket()+397<-qerhjGenProbeHashTable()+1571<-kdstf11011010000km()+673<-kdsttgr()+153241<-qertbFetch()+2455<-rwsfcd()+103<-qerhjFetch()+1661<-rwsfcd()+103<-qerhjFetch()+1661<-qergsFetch()+757<-qervwFetch()+139<-qerghFetch()+315<-qervwFetch()+139<-qerghFetch()+315<-opifch2()+2766<-kpoal8()+2833<-opiodr()+917<-ttcpip()+2183<-opitsk()+1710<-opiino()+969<-opiodr()+917<-opidrv()+570<-sou2o()+103<-opimai_real()+133<-ssthrdmain()+265<-main()+201<-__libc_start_main()+244
SQL> oradebug short_stack
ksedsts()+465<-ksdxfstk()+32<-ksdxcb()+1927<-sspuser()+112<-__sighandler()<-lmebco()+63<-qesaSimpleCompare()+73<-smbput()+913<-sorput()+93<-qergsRowP()+1067<-qerhjWalkHashBucket()+397<-qerhjGenProbeHashTable()+1571<-qerhjGenProbeHashTable()+718<-kdstf11011010000km()+673<-kdsttgr()+153241<-qertbFetch()+2455<-rwsfcd()+103<-qerhjFetch()+1661<-rwsfcd()+103<-qerhjFetch()+1661<-qergsFetch()+757<-qervwFetch()+139<-qerghFetch()+315<-qervwFetch()+139<-qerghFetch()+315<-opifch2()+2766<-kpoal8()+2833<-opiodr()+917<-ttcpip()+2183<-opitsk()+1710<-opiino()+969<-opiodr()+917<-opidrv()+570<-sou2o()+103<-opimai_real()+133<-ssthrdmain()+265<-main()+201<-__libc_start_main()+244

可以看到qerhjWalkHashBucket
qerhjWalkHashBucket就表示在做hash join的過程中需要遍歷hash bucket中的數據，當鏈接列數據分佈不均，某些值特別多時，遍歷其hash bucket的成本也就非常高，如果pga放不下了，就會放到temp進行磁碟io，這就是性能瓶頸的原因，這個例子把30g的temp表空間都撐爆了，可見hash bucket有多大！

做個SQL MONITOR，也可以看出，瓶頸在id 6。如果做一個sql rpt也可以發現sql執行過程中的每妙邏輯讀實際並不高，因為時間都花在了遍歷hash bucket中


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • Xamarin提示Build-tools版本過老
    Xamarin提示Build-tools版本過老 錯誤信息：G:\XamarinDemo\Xamarin.Forms-master\packages\Xamarin.Android.Support.Vector.Drawable.23.3.0\build\Xamarin.Android.Suppor ...
  • Android經典的單例模式
    當第一次載入Singleton類時不會初始化sInstance，只有在第一次調用Singleton的getInstance方法時才會導致sInstance被初始化。因此第一次調用getInstance方法會導致 虛擬機載入SingletonHolder類，這種方法不僅能夠確保線程安全，也能夠保證單例 ...
  • Xcode 8 新特性
    在2016 蘋果全球開發者大會(WWDC)期間, 蘋果一如既往地給開發者們披露了新版的集成開發工具 – Xcode, 在過去的每一次大版本發佈中，蘋果都會積極地改進開發工具，添加一些極具吸引力的新功能，今年也不例外。 1. Swift 2 and 3 過去每一版的Xcode 都和固定版本的Swift ...
  • android 很詳細的序列化過程Parcelable
    直接上代碼：註釋都寫的很清楚了。 public class Entry implements Parcelable{ public int userID; public String username; public boolean isMale; public Book book;//序列化對象可 ...
  • iOS逆向工程之KeyChain與Snoop-it
    今天博客的主題是Keychain, 在本篇博客中會通過一個登陸的Demo將用戶名密碼存入到KeyChain中,並且查看一下KeyChain中存的是什麼東西，把這些內容給導出來。當然本篇博客的重點不是如何使用Keychain來存儲你的用戶名和密碼了。不過今天的博客中會用到這些知識。Apple的開發著文 ...
  • 簡單的ViewPager瞭解Scroller類
    View滑動是自定義ViewGroup中十分常見的一個功能。Android提供了多種View滑動的方法。 1. layout方法 2. offsetLeftAndRight()與offsetTopAndBottom方法 3. LayoutParams方法 4. scrollTo 與scrollBy方 ...
  • Hadoop 安裝指南
    一、安裝JDK 1、用戶可以在Oracle JDK的官網下載相應版本的JDK，本例以JDK 1.6為例，官網地址為http://www.oracle.com/tech-network/java/javase/downloads/index.html。 2、配置環境變數，在/etc/profile增加 ...
  • redis集群配置
    1、環境準備 1）準備6台ubuntu虛擬機 2）配置好IP（192.168.1.36,192.168.1.37,192.168.1.38, 192.168.1.40，192.168.1.41,192.168.1.42 三台master 三台slave） 3）安裝好openssh-server 2、 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類