abdti主机dgyt库问题导致工单系统缓慢

发布时间：2020-08-07 23:38:26 来源：ITPUB博客阅读：105 作者：a635186971 栏目：关系型数据库

应用反馈工单系统缓慢，登上主机查询LOCAL=NO以及v$session数量，发现连数确实比平时高出50%以上。后来咨询业务，发现这是月底正常业务现象。

1、查看SunOS操作系统情况：
1)内存：

点击(此处)折叠或打开

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

    可见，该主机内存共32G，空闲11G，使用21G，使用率65%。
    查看数据库sga为10G，pga为1G，应该该主机只有dgyt库，所以sga配置太低，建议调整。
2）cpu
    mpstat 共16个逻辑cpu
    sar -u 3 20 cpu使用率15%
    而数据库已经使用了主机所有的16个cpu。
    cpu_count integer 16
3）IO
    由iostat -xd 2查看到各个盘的io较为繁忙，初步怀疑是IO导致数据库缓慢。
2）、查看数据库情况（10.2.0.5 基于asm的rac单实例）
1）查看数据库的等待事件：
    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等待事件导致。
2）查看导致direct path read的sql。
    select sql_id,username,count(*) from gv$session where event#=198 group by sql_id,username order by 3;
    得知基本是由于******用户的如下两个sql导致的：d7d83k6fzn7db和bbqffj0cd01xm
3)  查看对应的sql内容已经执行计划

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

点击(此处)折叠或打开

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 |
------------------------------------------------------------------------------------------------------

可以看到主要是部分表存在全表扫描，虽然表的数据量不大（约170w行），但是并发高的情况下可能还是会造成性能影响的。故考虑创建索引，如下：

点击(此处)折叠或打开

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)调整sga参数：
alter system set sga_max_target=20g scope=spfile sid='*';
重启库。
5）因在分析问题时，业务就已经恢复了。所以无法验证改动是否启作用，待后续观察是否业务故障是否会重现。

向AI问一下细节

abdti主机dgyt库问题导致工单系统缓慢

猜你喜欢

最新资讯

相关推荐

相关标签