abdti主机dgyt库问题导致工单系统缓慢
应用反馈工单系统缓慢，登上主机查询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）因在分析问题时，业务就已经恢复了。所以无法验证改动是否启作用，待后续观察是否业务故障是否会重现。
网页标题：abdti主机dgyt库问题导致工单系统缓慢
链接分享：
http://kswjz.com/article/ieoddi.html
扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
