查询突然变慢

显示全部楼层 · 2013-2-25 14:51:24

大家好，有个疑问，我的rac数据库之前重启了一次，现在查询比正常时候慢很多，我看了索引状态也正常，执行计划里也是正常走索引，临时表空间也无异常，请高手帮忙分析一下，我之前改了sga_target 的大小，现在为30g，也够用啊，pga为14g，sga查询结果如下：
select sum(pins) "executions", sum(reloads) "cachemisses",sum(reloads)/sum(pins)
3from v$librarycache;
executions cache
misses SUM(RELOADS)/SUM(PINS)
---------- ------------ ----------------------
64721349 431416
.006665745

千问 · 2013-2-25 14:51:24

就算是应解析，查询也非常慢啊，不太正常，

千问 · 2013-2-25 14:51:24

附件为我抓的trace有好心人帮忙看下吗

千问 · 2013-2-25 14:51:24

我之前还修改了 open_cursors
integer 20000
session_cached_cursors
integer 1000
这两个值不过应该没什么影响才对

千问 · 2013-2-25 14:51:24

这是我语句的执行计划，不单单是这个语句，只要是复杂sql查询变的都很慢，就算重启之后硬解析也不至于那么慢的，
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 413664063
----------------------------------------------------------------------------------------------------------------------------------------------
| Id| Operation
| Name
| Rows| Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT
|
| 50000 |39M| | 266K(1)| 00:53:24 | | |
|*1 |VIEW
|
| 50000 |39M| | 266K(1)| 00:53:24 | | |
|*2 | COUNT STOPKEY
|
| | | |
|
| | |
| 3 |VIEW
|
| 56214 |44M| | 266K(1)| 00:53:24 | | |
|*4 | SORT UNIQUE STOPKEY
|
| 56214 |17M|10M| 266K(1)| 00:53:24 | | |
| 5 |UNION-ALL
|
| | | |
|
| | |
| 6 | PARTITION RANGE ALL
|
| 56212 |9112K| | 264K(1)| 00:52:59 | 1 |31 |
|*7 |TABLE ACCESS BY LOCAL INDEX ROWID| T_APPLICATIONLOG5_201503 | 56212 |9112K| | 264K(1)| 00:52:59 | 1 |31 |
|*8 | INDEX RANGE SCAN
| I_APPLOG_LOGTYPE_5_201503|4356K| | | 11368 (1)| 00:02:17 | 1 |31 |
| 9 | PARTITION RANGE ALL
|
| 1 | 239 | |33 (0)| 00:00:01 | 1 |31 |
|10 |TABLE ACCESS BY LOCAL INDEX ROWID| T_APPLICATIONLOG14_201503| 1 | 239 | |33 (0)| 00:00:01 | 1 |31 |
|* 11 | INDEX RANGE SCAN
| I_APPLOG_LOGTYPE_14_201503 | 1 | | |32 (0)| 00:00:01 | 1 |31 |
|12 | PARTITION RANGE ALL
|
| 1 | 262 | | 2 (0)| 00:00:01 | 1 |31 |
|13 |TABLE ACCESS BY LOCAL INDEX ROWID| T_APPLICATIONLOG16_201503| 1 | 262 | | 2 (0)| 00:00:01 | 1 |31 |
|* 14 | INDEX RANGE SCAN
| I_APPLOG_LOGTYPE_16_201503 | 1 | | | 1 (0)| 00:00:01 | 1 |31 |
----------------------------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("RN">0)
2 - filter(ROWNUM<=50000)
4 - filter(ROWNUM<=50000)
7 - filter("MASTERLOGINID" IS NULL)
8 - access("T"."LOGTYPE"=1)
11 - access("T"."LOGTYPE"=1)
14 - access("T"."LOGTYPE"=1)
32 rows selected.

千问 · 2013-2-25 14:51:24

将sql直接在每个node上执行看看那台的sql plan有问题
rac中的每个instance的sql plan有可能会不同

千问 · 2013-2-25 14:51:24

binhu 发表于 2015-7-21 15:46
将sql直接在每个node上执行看看那台的sql plan有问题
rac中的每个instance的sql plan有可能会不同
是啊，我现在就是在一个节点上看的，，

千问 · 2013-2-25 14:51:24

景远思发表于 2015-7-21 15:47
是啊，我现在就是在一个节点上看的，，
其他的node上執行也很慢嗎?

千问 · 2013-2-25 14:51:24

binhu 发表于 2015-7-21 15:50
其他的node上執行也很慢嗎?
是啊，无论在哪个节点都慢

千问 · 2013-2-25 14:51:24

景远思发表于 2015-7-21 15:59
是啊，无论在哪个节点都慢
trace file的内容是真实数据吗?
如是的话，问一下ap为何要查3次t_applicationlog33_201503，程序写错了?
table: t_applicationlog33_201503有7百多万笔
where b.accountid not in (select distinct a.masterloginid

from t_applicationlog33_201503 a

where a.operatedata like '%操作成功%'

and a.result = '操作成功')
and b.accountid not in (select distinct a.masterloginid

from t_applicationlog33_201503 a

where a.operatedata like '%操作成功%'

and a.result = '操作成功')
and b.accountid not in (select distinct a.masterloginid

from t_applicationlog33_201503 a

where a.operatedata like '%操作成功%'

and a.result = '操作成功')