abdti主機dgyt庫問題導(dǎo)致工單系統(tǒng)緩慢

發(fā)布時間：2020-08-07 23:38:26 來源：ITPUB博客閱讀：119 作者：a635186971 欄目：關(guān)系型數(shù)據(jù)庫

應(yīng)用反饋工單系統(tǒng)緩慢，登上主機查詢LOCAL=NO以及v$session數(shù)量，發(fā)現(xiàn)連數(shù)確實比平時高出50%以上。后來咨詢業(yè)務(wù)，發(fā)現(xiàn)這是月底正常業(yè)務(wù)現(xiàn)象。

1、查看SunOS操作系統(tǒng)情況：
1)內(nèi)存：

點擊(此處)折疊或打開

root@abdit # prtconf |grep Memory
Memory size: 32768 Megabytes
root@abdit # echo "::memstat"|mdb -k
Page Summary Pages MB %Tot
------------ ---------------- ---------------- ----
Kernel 364339 2846 9%
Anon 2158855 16866 52%
Exec and libs 74791 584 2%
Page cache 62215 486 2%
Free (cachelist) 1391728 10872 34%
Free (freelist) 65421 511 2%
Total 4117349 32166
Physical 4095711 31997

    可見，該主機內(nèi)存共32G，空閑11G，使用21G，使用率65%。
    查看數(shù)據(jù)庫sga為10G，pga為1G，應(yīng)該該主機只有dgyt庫，所以sga配置太低，建議調(diào)整。
2）cpu
    mpstat 共16個邏輯cpu
    sar -u 3 20 cpu使用率15%
    而數(shù)據(jù)庫已經(jīng)使用了主機所有的16個cpu。
    cpu_count integer 16
3）IO
    由iostat -xd 2查看到各個盤的io較為繁忙，初步懷疑是IO導(dǎo)致數(shù)據(jù)庫緩慢。
2）、查看數(shù)據(jù)庫情況（10.2.0.5 基于asm的rac單實例）
1）查看數(shù)據(jù)庫的等待事件：
    select event#，event，count(*) from v$session group by event#,event order by 3;

點擊(此處)折疊或打開

EVENT# EVENT COUNT(*)
---------- ------------------------------ ----------
150 db file parallel write 1
135 log file parallel write 1
199 direct path read temp 1
350 SQL*Net message to client 1
200 direct path write 1
201 direct path write temp 2
144 log file sync 10
148 db file scattered read 11
147 db file sequential read 14
98 read by other session 205
198 direct path read 342

    可見主要的問題都是direct path read以及read by other session等待事件導(dǎo)致。
2）查看導(dǎo)致direct path read的sql。
    select sql_id,username,count(*) from gv$session where event#=198 group by sql_id,username order by 3;
    得知基本是由于******用戶的如下兩個sql導(dǎo)致的：d7d83k6fzn7db和bbqffj0cd01xm
3)  查看對應(yīng)的sql內(nèi)容已經(jīng)執(zhí)行計劃

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('bbqffj0cd0qxm',NULL));
得知內(nèi)容如下：

點擊(此處)折疊或打開

select title, itemid,formId,predictFinishTime
from (select mw.title,mw.itemid,mw.itemtype as formId,ia.predictFinishTime
from ta_***** tp,form_****** fw,mw_workitem mw,Item_******* ia
where tp.****='waiting'
and (tp.defName='??t·?? or tp.defName='??·?? or tp.defName='??·??)
and tp.rootinstid = fw.processid
and fw.itemid =mw.itemid
and mw.relatingRoom in ('2??ф-2???

點擊(此處)折疊或打開

------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 17302 (100)| |
| 1 | COUNT STOPKEY | | | | | |
| 2 | HASH JOIN | | 1 | 265 | 17302 (1)| 00:03:28 |
| 3 | NESTED LOOPS | | 4 | 812 | 10380 (1)| 00:02:05 |
| 4 | NESTED LOOPS | | 2752 | 812 | 10380 (1)| 00:02:05 |
| 5 | HASH JOIN | | 344 | 52632 | 8660 (1)| 00:01:44 |
| 6 | TABLE ACCESS FULL | MW_***** | 342 | 37962 | 8006 (1)| 00:01:37 |
| 7 | TABLE ACCESS FULL | FORM_***** | 290K| 11M| 652 (1)| 00:00:08 |
| 8 | INDEX RANGE SCAN | TAI_*****_ROOTID | 8 | | 2 (0)| 00:00:01 |
| 9 | TABLE ACCESS BY INDEX ROWID| TA_***** | 1 | 50 | 5 (0)| 00:00:01 |
| 10 | TABLE ACCESS FULL | ITEM_****** | 601K| 35M| 6918 (1)| 00:01:24 |
------------------------------------------------------------------------------------------------------

可以看到主要是部分表存在全表掃描，雖然表的數(shù)據(jù)量不大（約170w行），但是并發(fā)高的情況下可能還是會造成性能影響的。故考慮創(chuàng)建索引，如下：

點擊(此處)折疊或打開

create index *****.idx_*****_****_**** on ****.Item_******(***,***,****) online parallel 8 tablespace TBS_*****;
create index *****.idx_***** on *****.form_**** (*****) online tablespace TBS_*****;
create index *****.idx_*****_***** on *****.MW_****(*****,*****) online tablespace TBS_*****;

4)調(diào)整sga參數(shù)：
alter system set sga_max_target=20g scope=spfile sid='*';
重啟庫。
5）因在分析問題時，業(yè)務(wù)就已經(jīng)恢復(fù)了。所以無法驗證改動是否啟作用，待后續(xù)觀察是否業(yè)務(wù)故障是否會重現(xiàn)。

向AI問一下細節(jié)

abdti主機dgyt庫問題導(dǎo)致工單系統(tǒng)緩慢

猜你喜歡

最新資訊

相關(guān)推薦

相關(guān)標簽