应用反馈工单系统缓慢,登上主机查询LOCAL=NO以及v$session数量,发现连数确实比平时高出50%以上。后来咨询业务,发现这是月底正常业务现象。
1、查看SunOS操作系统情况:
1)内存:
可见,该主机内存共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;
可见主要的问题都是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内容已经执行计划
alter system set sga_max_target=20g scope=spfile sid='*';
重启库。
5)因在分析问题时,业务就已经恢复了。所以无法验证改动是否启作用,待后续观察是否业务故障是否会重现。
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
查看数据库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
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));
得知内容如下:
可以看到主要是部分表存在全表扫描,虽然表的数据量不大(约170w行),但是并发高的情况下可能还是会造成性能影响的。故考虑创建索引,如下:
4)调整sga参数:
得知内容如下:
点击(此处)折叠或打开
- 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 |
- ------------------------------------------------------------------------------------------------------
点击(此处)折叠或打开
- 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_*****;
alter system set sga_max_target=20g scope=spfile sid='*';
重启库。
5)因在分析问题时,业务就已经恢复了。所以无法验证改动是否启作用,待后续观察是否业务故障是否会重现。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31441616/viewspace-2152424/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/31441616/viewspace-2152424/