查看: 1464|回复: 9

[讨论] EXADATA X2全表扫描等待事件90%为单块读?

[复制链接]
论坛徽章:
0
发表于 2017-11-20 19:43 | 显示全部楼层 |阅读模式
环境exadata x2 4节点
数据库11.2.0.4 bi数据仓库

普通的3张表堆表,1小2大,普通的hash join,小表和其中一张大表hash join,再和另外一张表join,执行计划为TABLE ACCESS STORAGE FULL

使用sql monitor跟踪,一开始小表和大表join,瓶颈大表全表扫描90%都是单块读,10%为cell smart scan,cpu消耗很高

如下原因基本排除,还有可能是什么原因
1.db_file_multiblock_read_count>1
2.我开了并行,排除buffer cache缓冲
3.少量的段头块读,我基本都是单块读
4.行链接,没有
5.lob , 没有
6.在我执行sql之前之后表上都没有事物,排除大量undo块读取。

系统当时处于空闲时间段,cpu内存都不忙,还有什么原因会影响exadata选择offloading?
最起码也应该是多块读??

在此求助大神,先谢过了。
认证徽章
论坛徽章:
8
2009新春纪念徽章
日期:2009-01-04 14:52:28祖国60周年纪念徽章
日期:2009-10-09 08:28:002010新春纪念徽章
日期:2010-03-01 11:07:24ITPUB9周年纪念徽章
日期:2010-10-08 09:32:25ITPUB十周年纪念徽章
日期:2011-11-01 16:23:262013年新春福章
日期:2013-02-25 14:51:24沸羊羊
日期:2015-03-04 14:51:522015年新春福章
日期:2015-03-06 11:57:31
发表于 2017-11-20 21:47 | 显示全部楼层
建议楼主把分析的材料直接贴出来,这样,大家才能更好的分析讨论。

使用道具 举报

回复
论坛徽章:
74
ITPUB18周年纪念章
日期:2018-09-17 10:09:49双子座
日期:2016-01-19 20:35:54秀才
日期:2016-01-13 12:14:26秀才
日期:2015-12-25 15:31:10秀才
日期:2015-12-18 09:28:57秀才
日期:2015-12-14 14:56:09秀才
日期:2015-12-14 14:51:16秀才
日期:2015-11-30 09:13:06处女座
日期:2015-11-27 12:27:01秀才
日期:2015-11-23 10:17:19
发表于 2017-11-21 11:38 | 显示全部楼层
行迁移也可能会导致。但是信息不够,没法下结论。把sql monitor报告贴出来。

使用道具 举报

回复
论坛徽章:
22
问答徽章
日期:2014-01-06 16:50:41秀才
日期:2015-10-26 09:55:08秀才
日期:2015-11-11 09:48:44秀才
日期:2015-11-11 10:22:49秀才
日期:2015-11-12 17:43:40秀才
日期:2015-12-14 15:02:13秀才
日期:2016-01-21 13:42:39秀才
日期:2016-01-25 14:55:31秀才
日期:2016-02-18 10:08:14秀才
日期:2016-03-24 09:20:52
发表于 2017-11-21 13:39 | 显示全部楼层
把执行计划贴出来,查一下统计信息是否是最新的

使用道具 举报

回复
论坛徽章:
0
 楼主| 发表于 2017-11-21 16:54 | 显示全部楼层
sql_monitor见附件
1.jpg

使用道具 举报

回复
认证徽章
论坛徽章:
8
2009新春纪念徽章
日期:2009-01-04 14:52:28祖国60周年纪念徽章
日期:2009-10-09 08:28:002010新春纪念徽章
日期:2010-03-01 11:07:24ITPUB9周年纪念徽章
日期:2010-10-08 09:32:25ITPUB十周年纪念徽章
日期:2011-11-01 16:23:262013年新春福章
日期:2013-02-25 14:51:24沸羊羊
日期:2015-03-04 14:51:522015年新春福章
日期:2015-03-06 11:57:31
发表于 2017-11-22 15:23 | 显示全部楼层
本帖最后由 sqysl 于 2017-11-22 15:25 编辑
oilz 发表于 2017-11-21 16:54
sql_monitor见附件

可能是HCC压缩表上的DML操作导致的行迁移(HCC->OLTP),而这些迁移行(OLTP压缩)再次被访问时导致发生大量的cell single block physical read,结果就是,性能差,消耗CPU较高。解决办法就是不要对频繁更新的表应用HCC设置。

使用道具 举报

回复
论坛徽章:
74
ITPUB18周年纪念章
日期:2018-09-17 10:09:49双子座
日期:2016-01-19 20:35:54秀才
日期:2016-01-13 12:14:26秀才
日期:2015-12-25 15:31:10秀才
日期:2015-12-18 09:28:57秀才
日期:2015-12-14 14:56:09秀才
日期:2015-12-14 14:51:16秀才
日期:2015-11-30 09:13:06处女座
日期:2015-11-27 12:27:01秀才
日期:2015-11-23 10:17:19
发表于 2017-11-22 15:38 | 显示全部楼层
oilz 发表于 2017-11-21 16:54
sql_monitor见附件

最好是把XML的贴出来,光看这个截图信息不够完整。
不过肯定是那个表出问题了,更新HCC表很容易导致。最好不要在HCC表大量更新。现在最快的方法是把表ctas一个新表再rename。然后你这几个JOIN表很大,并行度可以适当再开大一些,比如16。

使用道具 举报

回复
论坛徽章:
0
 楼主| 发表于 2017-11-23 20:20 | 显示全部楼层
怎么验证为行迁移,analyze吗?还有应该不是HCC表,我明天去确认下。

使用道具 举报

回复
论坛徽章:
0
 楼主| 发表于 2017-11-23 20:27 | 显示全部楼层
有没有更为直接的方法能看到oracle为什么没有选择smart scan,就像10053那样,直接告诉你为什么没有选择某个plan

使用道具 举报

回复
认证徽章
论坛徽章:
8
2009新春纪念徽章
日期:2009-01-04 14:52:28祖国60周年纪念徽章
日期:2009-10-09 08:28:002010新春纪念徽章
日期:2010-03-01 11:07:24ITPUB9周年纪念徽章
日期:2010-10-08 09:32:25ITPUB十周年纪念徽章
日期:2011-11-01 16:23:262013年新春福章
日期:2013-02-25 14:51:24沸羊羊
日期:2015-03-04 14:51:522015年新春福章
日期:2015-03-06 11:57:31
发表于 2017-11-24 21:18 | 显示全部楼层
本帖最后由 sqysl 于 2017-11-24 21:25 编辑
oilz 发表于 2017-11-23 20:27
有没有更为直接的方法能看到oracle为什么没有选择smart scan,就像10053那样,直接告诉你为什么没有选择某 ...

试试这个呢。
SELECT compression_type, sum(rws) n_rows
          FROM  (
                 SELECT decode(dbms_compression.get_compression_type(USER, 'TAB_NAME', min_rowid),
                        1, 'No Compression',
                        2, 'Basic/OLTP Compression',
                        4, 'HCC Query High',
                        8, 'HCC Query Low',
                       16, 'HCC Archive High',
                       32, 'HCC Archive Low',
                       64, 'From HCC to OLTP',
                           'Unknown Compression Level' ) AS compression_type, rws
                   FROM (
                         SELECT min(rowid) as min_rowid,count(*) as rws
                           FROM TAB_NAME
                          GROUP BY dbms_rowid.rowid_block_number(rowid)
                         )
                 )
        GROUP  BY compression_type;

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

第67期:Neo4j图数据库平台架构最佳实践
【微学堂】10月18日 20:00(周四)

当下,数据的规模和类型每时每刻都在呈几何级数的增长,仅能够管理大量的数据是不够的,关键是能从海量数据中发掘出有用的信息,特别是数据之间的关联,能高效存储和处理数据之间关联的新型数据库为图数据库。 本讲座将介绍Neo4j图数据库的基本概念、设计特点、架构和经典应用场景实战分享。

进入课堂>>
TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 
京ICP备16024965号 北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表