ITPUB论坛-中国最专业的IT技术社区

 
 注册
热搜:
查看: 963|回复: 9

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

[复制链接]
论坛徽章:
0
跳转到指定楼层
1#
发表于 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
2#
发表于 2017-11-20 21:47 | 只看该作者
建议楼主把分析的材料直接贴出来,这样,大家才能更好的分析讨论。

使用道具 举报

回复
论坛徽章:
69
山治
日期:2017-09-11 19:15:33处女座
日期:2015-11-27 12:27:01秀才
日期:2015-11-23 10:17:19秀才
日期:2015-11-23 09:57:36金牛座
日期:2016-04-01 18:05:22秀才
日期:2015-11-11 10:22:49摩羯座
日期:2015-08-20 16:22:52秀才
日期:2015-08-31 13:02:54秀才
日期:2015-12-25 15:31:10巨蟹座
日期:2015-11-04 12:43:04
3#
发表于 2017-11-21 11:38 | 只看该作者
行迁移也可能会导致。但是信息不够,没法下结论。把sql monitor报告贴出来。

使用道具 举报

回复
论坛徽章:
22
问答徽章
日期:2014-01-06 16:50:41秀才
日期:2015-09-21 09:46:16秀才
日期:2015-11-12 17:43:40秀才
日期:2015-11-11 09:48:44秀才
日期:2015-11-11 10:22:49秀才
日期: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
4#
发表于 2017-11-21 13:39 | 只看该作者
把执行计划贴出来,查一下统计信息是否是最新的

使用道具 举报

回复
论坛徽章:
0
5#
 楼主| 发表于 2017-11-21 16:54 | 只看该作者
sql_monitor见附件

1.jpg (991.65 KB, 下载次数: 23)

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
6#
发表于 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设置。

使用道具 举报

回复
论坛徽章:
69
山治
日期:2017-09-11 19:15:33处女座
日期:2015-11-27 12:27:01秀才
日期:2015-11-23 10:17:19秀才
日期:2015-11-23 09:57:36金牛座
日期:2016-04-01 18:05:22秀才
日期:2015-11-11 10:22:49摩羯座
日期:2015-08-20 16:22:52秀才
日期:2015-08-31 13:02:54秀才
日期:2015-12-25 15:31:10巨蟹座
日期:2015-11-04 12:43:04
7#
发表于 2017-11-22 15:38 | 只看该作者
oilz 发表于 2017-11-21 16:54
sql_monitor见附件

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

使用道具 举报

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

使用道具 举报

回复
论坛徽章:
0
9#
 楼主| 发表于 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
10#
发表于 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;

使用道具 举报

回复

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

本版积分规则

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