1   内存数据库测试

在pdba下创建一张表：

create table inmem_test as select * from

dba_source;

SQL> select count(*) from dba_source;

COUNT(*)

----------

342744

insert into inmem_test

select 'fd'||owner||'sfd'

a,'gvj'||name||'af4s' b,type,'6'||line||'73' c,text d,ORIGIN_CON_ID||'56' e

from inmem_test;

SQL> SELECT COUNT(*) FROM inmem_test;

COUNT(*)

----------

2056464

SQL> select

owner,table_name,STATUS,CACHE,LAST_ANALYZED,INMEMORY,INMEMORY_PRIORITY,INMEMORY_DISTRIBUTE,INMEMORY_COMPRESSION,INMEMORY_DUPLICATE

from dba_tables where table_name='INMEM_TEST';

OWNER       TABLE_NAME

STATUS   CACHE LAST_ANALYZED       INMEMORY INMEMORY INMEMORY_DISTRI

INMEMORY_COMPRESS INMEMORY_DUPL

--------------- ---------- -------- -----

------------------- -------- -------- --------------- -----------------

-------------

PDBA        INMEM_TEST

VALID    N 2014/12/31 09:35:20 DISABLED

SQL> select

owner,segment_name,segment_type,BYTES/1024/1024

size_MB,BLOCKS,EXTENTS,INMEMORY,INMEMORY_COMPRESSION FROM DBA_SEGMENTS WHERE

SEGMENT_NAME like 'INMEM%';

OWNER      SEGMENT_NAME    SEGMENT_TYPE      SIZE_MB     BLOCKS

EXTENTS INMEMORY INMEMORY_COMPRESS

---------- ---------------

------------------ ---------- ---------- ---------- -------- -----------------

PDBA       INMEM_TEST      TABLE             408

52224    122 DISABLED

系统内存情况检查：

SELECT

MAX(LINE) FROM INMEM_TEST;

创建同样的表：

create table inmem_in_test as select * from

inmem_test;

select count(*) from inmem_in_test;

SELECT

MAX(LINE) FROM INMEM_TEST;

从上述结果看到两张表的大小应该是不一样的，我们可以采取move操作事宜一样大小：

在查询：

此两张表的同样的执行语句得到的统计数据应该是一致的可以看看：

可以看到跟预期的是一样的，我们开始将表inmem_in_test修改为in-memory模式：

alter table inmem_in_test inmemory;

select

owner,segment_name,segment_type,BYTES/1024/1024

size_MB,BLOCKS,EXTENTS,INMEMORY,INMEMORY_COMPRESSION FROM DBA_SEGMENTS WHERE

SEGMENT_NAME like ‘INMEM%’

表已经修改为in-memory模式了，开始做一次同样的查询：

SELECT MAX(LINE) FROM INMEM_IN_TEST;

有大量的物理读，再次和执行：

任然存在物理读，只不过少了很多，为什么还存在物理读呢？

我们在对表inmem_test进行cache后在执行：

发现仍然存在物理读？原因主要是这其实是11g之后的新特性，大表就不经过缓存，直接走direct path read。为了避免该特性影响对比，我们用event将其屏蔽

alter session set events

'10949 trace name context forever, level 1';

修改后的查询中仍然存在大量的物理读情况。

再次确认操作系统内存情况，大约为4.2G：

修改memory_max_target为2092M,同时相应的修改memory_target重启数据库后再次进行测试:

开始测试：

再次测试inmemory表：

虽有减少，但是仍然存在大量的物理读。

再次修改inmemory进行测试：

开始测试:

此时物理读的量更大了，在看非inmemory表的测试：

alter session set events '10949 trace name

context forever, level 1';

现在讲内存全部修改会原来的值。第一次运行：

第二次运行：

可以看到几乎瞬间就完成了，同时一致性读、物理读几乎为0。

对非inmemory表进行测试再次测试：

可以看到仍然有大量的物理读一致性读。对此运行后同样存在。

在对表的内存压缩能力进行检查：

此处可以看到我们采用的压缩方式为默认，这种压缩主要是为了提高query的效率，我们如果要求更高的压缩效率可以采用其他压缩，简单测试如下：

测试压缩后的查询效率：

可以看到压缩后的查询效率更高了。

此处限于本身测试环境的内存限制，测试至此，我们可以简单得出如下结果：

结论：

1、inmemory表第一次加载时需要较长的时间，在条件相同的情况下内存在内存中表的query效率远远大于no inmemory表效率。

2、inmemory内存区别于oracle已有内存结构PGA、SGA、或者新的memory设定。

3、inmemory采用不同的压缩级别对数据的压缩率不同，同样针对数据的增删改查的效率也不同。

4、此外根据oracle官方文档说明，在内存足够大的情况下可以将整个数据库强制到内存中成为内存数据库。

5、常用的inmemory视图：

SQL> select object_name from dba_objects

where object_name like 'V$IM%';

OBJECT_NAME

-------------------------------------------------------------------------------V$IM_COLUMN_LEVEL

V$IM_COL_CU

V$IM_HEADER

V$IM_SEGMENTS

V$IM_SEGMENTS_DETAIL

V$IM_SEG_EXT_MAP

V$IM_SMU_CHUNK

V$IM_SMU_HEAD

V$IM_TBS_EXT_MAP

V$IM_USER_SEGMENTS