inmemory option的简单介绍和测试

12c的inmemory option 已经在6月10日发布,预计会在7月份有正式的产品release,即在12.1.0.2中,你就可以看到这个新特性了。

下面我们来简单看看这个新特性的用法和体会一下其厉害之处。

上面的几个参数和inmemory option有关。

常用的检查视图:

我们来测试一下:

好,我们正式开始对比测试,每个语句跑3次。

(1)用cache的情况:

我们很奇怪的发现,3次运行,时间在4秒左右,consistent gets为7886,始终有physical reads。这是怎么回事?为什么始终有physical reads?

这其实是11g之后的新特性,大表就不经过缓存,直接走direct path read。为了避免该特性影响对比,我们用event将其屏蔽。

(1.1)屏蔽direct path read后,再次测试用cache的情况

我们看到基本的运行时间在3秒左右。consistent gets为7892,无physical reads。

好,轮到主角登场,我们来看看。

(2)测试用inmemory option的情况:

运行时间几乎是0秒,且consistent gets只有3!没有physical reads。

注意上面执行计划中的 TABLE ACCESS INMEMORY FULL,是显示了使用哦inmemory option。

太强大了,我已经不知道该说什么好了……








==== update 2014-06-18=========================

应木匠同学的要求,再加一次display_cursor和statistics_level=all测试。:)

这次用了4100多万的数据。测试如下:

可以看到bytes还是有变化的。

相关文章

3条评论

  1. 能不能用 RunStats 或者 dbms_xplan.display_cursor + statistics_level = ALL , 再跑一边 ? 看看详细的资源消耗.

    两个 execution plan 里面, 都是Bytes 1322K. 鄙人以为 应该有区别.

    Thanks,
    木匠

  2. 您好 我安装了oracle12c 并且默认创建了一个pdb 名字为pdborcl,但是不知道该如何使用pl/sql developer或者sql developer连接pdb呢? 如能告知:感激不尽!

    yanwushu@163.com

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据