新迁移到p595 10gRAC慢啊~求指教

ricky

情况说明：  现在新迁移到了新系统上面，老库是一个10.2.0.5的单实例，新库是 10gRAC 10.2.0.5  
现在系统还没有上线移交，但是从我们的测试和使用发现，新库跑一个sql的时间是老库的两倍。其他sql更不要说，总体新库的性能很慢。

环境：
老库
pc刀片机
os： [oracle@localhost ~]$ uname -a
Linux localhost.localdomain 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
数据库：10.2.0.5

新库
P595
os：aix
10.2.0.5 RAC

现象：总体性能很慢
比如执行一个sql：select count(*) from tb_proc_perf  新库居然是老库的两倍时间；
该表已经做过分析，表数据是一样滴~

共同之处：参数和sga 等参数相同
不同之处：新库rac使用了异步IO 参数 filesystemio_options  = asynch

question：从哪里下手分析新系统rac的缓慢原因？给点思路指导一下。实在想不出。希望能够给点思路或是方法分析一下新系统慢的原因。谢谢

ricky

新库执行计划：

老库执行计划

ricky

新库使用时间：104秒
执行计划：
10:26:30 SQL> select * from tb_proc_perf t where t.createdate between '20130501140427' and '20130531140427';

Execution Plan
----------------------------------------------------------
Plan hash value: 16178747

----------------------------------------------------------------------------------
| Id  | Operation         | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |              |    61 |  3111 |   160K  (2)| 00:32:08 |
|*  1 |  TABLE ACCESS FULL| TB_PROC_PERF |    61 |  3111 |   160K  (2)| 00:32:08 |
----------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("T"."CREATEDATE"<='20130531140427' AND
              "T"."CREATEDATE">='20130501140427')


Statistics
----------------------------------------------------------
        457  recursive calls
          0  db block gets
     719311  consistent gets
     552739  physical reads
        116  redo size
        906  bytes sent via SQL*Net to client
        481  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          5  sorts (memory)
          0  sorts (disk)
          0  rows processed

10:28:14 SQL>


老库时间：27秒
执行计划：
10:23:29 SQL> select * from tb_proc_perf t where t.createdate between '20130501140427' and '20130531140427';

no rows selected


Execution Plan
----------------------------------------------------------
Plan hash value: 373438921

----------------------------------------------------------------------------------
| Id  | Operation         | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |              |    63 |  3213 |   214K  (3)| 00:42:51 |
|*  1 |  TABLE ACCESS FULL| TB_PROC_PERF |    63 |  3213 |   214K  (3)| 00:42:51 |
----------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("T"."CREATEDATE"<='20130531140427' AND
              "T"."CREATEDATE">='20130501140427')


Statistics
----------------------------------------------------------
          1  recursive calls
          2  db block gets
    1067846  consistent gets
     851603  physical reads
        176  redo size
        906  bytes sent via SQL*Net to client
        481  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          0  rows processed

10:23:56 SQL>

lnwxzyp

很明显，新库的执行计划要比老库的一致性读和物理读都要小，从OS层面去查找原因吧。。

以前 云南二枢那边出现过一次，也是速度很慢，后来查到是CPU配置的问题，haoshidong解决的，让你们管小机去查查。

ricky

PL/SQL里面执行验证 。同样的sql和同样的数据  确实是新库慢
老库：

新库

不了峰

关闭新库一个实例看看，是否是由cache fusion引起

  457  recursive calls  --这个新库比老库大了很多
并且还有一点的redo size 产生。

查询的时候，数据被更新？

或是数据是刚刚被加载进来的？？

再查第二遍，情况是否有改善？

ricky

不了峰 发表于 2013-10-24 11:09
关闭新库一个实例看看，是否是由cache fusion引起

  457  recursive calls  --这个新库比老库大了很多

好 测试一下

Maclean Liu(刘相兵

给出新老库的AWR ， 以及 针对该 SQL的awrsqrpt ， 不要用set time on ，要用set timing on!

还需要2楼SQL的 10046 raw trace, 主要是raw trace ，打包压缩上传

ricky

找了个实际生产的sql。生成sql trace
附件打包你要的东西

yangyanfei

新的awrsqrpt的io wait 比老的大多了。。另外trace文件中有 WARNING:Could not lower the asynch I/O limit to 160 for SQL direct I/O. It is set to -1
是否是bug 10205版本上的BUG？补丁 9969588

Maclean Liu(刘相兵

如果你确定 新老的存储是一个级别的话， 我想 就是文件系统缓存导致的，你老系统有文件系统缓存 当数据不在buffer cache里而在fs cache里的时候 对比会发觉用ASM的性能差很多， 这是正常的

老系统



新系统

Maclean Liu(刘相兵

PS:你的10046 trace 里没有等待事件，我想是因为你不会做10046 导致的， 我想到我的博客上找一下10046 怎么做很容易

ricky

Maclean Liu(刘相兵 发表于 2013-10-24 16:15
PS:你的10046 trace 里没有等待事件，我想是因为你不会做10046 导致的， 我想到我的博客上找一下10046 怎么 ...

哦 好 我重新做个10046 给你发上来 我做了级别1的，想问问你需要哪个级别？

ricky

ricky 发表于 2013-10-24 16:41
哦 好 我重新做个10046 给你发上来 我做了级别1的，想问问你需要哪个级别？ ...

我做了8级别的trace，请帮忙在看一下，谢谢~~