导航：首页 > 数据库 >

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

发表于：2026-11-02 作者：千家信息网编辑

千家信息网最后更新 2026年11月02日，应用反馈工单系统缓慢，登上主机查询LOCAL=NO以及v$session数量，发现连数确实比平时高出50%以上。后来咨询业务，发现这是月底正常业务现象。1、查看SunOS操作系统情况：1)内存：点击(

千家信息网最后更新 2026年11月02日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_*****;