[紧急]同样的库，同样的执行计划，10g RAC上运行比单机上运行慢

wing hong

原帖由 tolywang 于 2009-12-9 18:07 发表
备注：  都是分区表 。

1360 万的表全表扫描，QC上居然只要4秒钟

这个SQL返回值大概为12万  (可怕的报表系统啊)  ， 他们以用户要求为准，NND,  一个借口就是，QC DB上跑的
还好啊，为什么在 RAC production db上那么慢  ？

how long to do a full table scan on the same table on RAC PROD ?

wing hong

原帖由 tolywang 于 2009-12-9 18:49 发表
都是物理内存 32G ,  QC机器SGA给了 4G ,  Production RAC给了 20G .

Does the QC machine use file system ? Probably the data blocks are in file system cache already.


How about the RAC one ? use ASM ?

wing hong

can u run the same query on both QC and RAC and capture the run time stats like this ?

alter session set statistics_level ='ALL';
run query ;

SELECT * FROM TABLE(dbms_xplan.display_cursor(FORMAT=>'ALLSTATS LAST'));

that should give us a better idea.

and last test, turn on 10046 trace  to see where the time spent on RAC prod.

tolywang

原帖由 wing hong 于 2009-12-10 16:07 发表



how long to do a full table scan on the same table on RAC PROD ?

it take 3~4 mins ,  sometimes  1 mins  to run the same SQL  

Ocfs2 file system , not use ASM .

tolywang

原帖由 wing hong 于 2009-12-10 16:14 发表
can u run the same query on both QC and RAC and capture the run time stats like this ?

alter session set statistics_level ='ALL';
run query ;

SELECT * FROM TABLE(dbms_xplan.display_cursor(FORMAT=>'ALLSTATS LAST'));

that should give us a better idea.

and last test, turn on 10046 trace  to see where the time spent on RAC prod.

ok , I will try , thanks .

wing hong

原帖由 tolywang 于 2009-12-10 18:33 发表



it take 3~4 mins ,  sometimes  1 mins  to run the same SQL  

Ocfs2 file system , not use ASM .

so looks just the slowness of ocfs2 , is this consistent ?

not familiar with ocfs2, no sure why you would use it for PROD ?

My impression is that it is not that good to be used in PROD in terms of performance as well as stability.

what does the QC system use then ?

microsoft_fly

10046
or
只连其中一个节点看看效果

tolywang

原帖由 wing hong 于 2009-12-10 18:41 发表


so looks just the slowness of ocfs2 , is this consistent ?

not familiar with ocfs2, no sure why you would use it for PROD ?

My impression is that it is not that good to be used in PROD in terms of performance as well as stability.

what does the QC system use then ?

我们有3套OCFS2的RAC系统, 前2套分别运行1~2年多没有发现这样的问题，他们同样也有QC DB (linux ext3 file system) ，应用
方面也都是OLTP+Report 这种模式 。 还有一套GFS文件系统RAC的也很正常 。


这套系统本来是3个节点，刚开始导入数据的时候很正常，运行了几天， 后来正式准备上线的时候，发现建立Index的时候非常慢，没有
数据的Table 建立一个Index居然需要20多分钟， 没有办法，关闭了节点2 （因为节点2 的LUN 的label和节点1，3不同，有些怀疑），
结果回复正常 。 目前一直是1，3节点在运行，节点2的信息也没有清理(没有停机时间) 。

心跳线switch 用的是比较老的 cisco 2948 , 用过几年的，不知道有没有影响。

wing hong

原帖由 tolywang 于 2009-12-10 22:51 发表



我们有3套OCFS2的RAC系统, 前2套分别运行1~2年多没有发现这样的问题，他们同样也有QC DB (linux ext3 file system) ，应用
方面也都是OLTP+Report 这种模式 。 还有一套GFS文件系统RAC的也很正常 。


这套系统本来是3个节点，刚开始导入数据的时候很正常，运行了几天， 后来正式准备上线的时候，发现建立Index的时候非常慢，没有
数据的Table 建立一个Index居然需要20多分钟， 没有办法，关闭了节点2 （因为节点2 的LUN 的label和节点1，3不同，有些怀疑），
结果回复正常 。 目前一直是1，3节点在运行，节点2的信息也没有清理(没有停机时间) 。

心跳线switch 用的是比较老的 cisco 2948 , 用过几年的，不知道有没有影响。

i c. looks something wrong the config/status etc of the ocfs2. maybe you can check the error log etc .

qingcheng_yuan

mark