应用反馈工单系统缓慢，登上主机查询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）因在分析问题时，业务就已经恢复了。所以无法验证改动是否启作用，待后续观察是否业务故障是否会重现。
