LOGO

史跃东老师

主讲课程

  • .Oracle 11g OCP认证培训
  • .Hadoop 生态系统实战与案例解析
  • .Cloudera CCA Administrator-Apache Hadoop认证管理员
  • .Cloudera Developer Training for Spark and Hadoop
  • .Oracle 数据库性能优化
  • .Oracle 数据库高可用技术
  • .Oracle 数据库备份恢复
  • .Oracle 11g OCM 认证培训
  • .华为大数据HCNA认证
  • .华为大数据HCNP资深开发者认证课程
  • .Oracle 12c OCP-SQL
  • .Oracle 12c OCP-数据库管理
  • .Oracle 12c OCP-备份恢复
  • .Oracle 12c OCP认证培训
  • .MySQL OCP认证培训课程大纲
  • .华为HCIE-Big Data大数据专家认证
  • .国际认证预备课程
  • .大数据 + AI 精英班课程

Oracle Database 12C 之In-Memory(十二)

  • 发布日期:
  • 2018-05-03
  • 浏览次数:
  • 408
  • 分享

前面的系列文章及测试,基本都是在探讨当对象启用IM选项时,对查询性能能够有多大提升,以及如何提升。但是在实际的环境中,我们除了用select语句来查询数据之外,还会有其他的DML操作。比如说update,delete,以及insert。


我们知道,当我们进行这样的数据修改操作时,会使用db buffer cache来缓存并修改数据,redo信息写入到redo log,undo信息循环使用undo表空间。当启用对象的IM功能时,进行DML操作,redo与undo内容的更新,这些还是照旧。只不过,oracle会在IM中也维护相应的内容,以保证IM中的数据和db buffer cache中的数据一致。

对于IM中的每个IMCU,都会在IM中维护一份相应的事务日志(Transaction Journal)。当DML操作在IMCU中更新IM对象的某条记录后,则该记录就会被标记为’stale’(过期),同时会在IM事务日志中保存该条记录的最新版本。为了维护读取操作的数据一致性,IMCU中标记为’stale’的数据并不会立即被替换。


当IMCU中stale数据的数量越多时,则对IMCU的访问就会变得越慢,所以需要在stale数据达到一定的阈值后,启用Repopulate操作来重新装载该IMCU的数据。这里的阈值会由Oracle综合考虑IMCU的访问频率以及stale数据的比例后在内部确定。Repopulation操作是由Oracle后台进程来online执行的。除此之外,IMCO(In Memory Coordinator)后台进程还会调用Trickle Repopulation机制来帮助作Repopulation工作,详见《White Paper In memory》。


关于 oracle数据库In-Memory白皮书这个东东,可以到oracle官网去下载,链接如下:

http://www.oracle.com/technetwork/database/in-memory/overview/index.html

恩,也不是很长,20多页,有兴趣的小伙伴也可以尝试把它翻译成中文哈:)


我们看看相关实验:

SCOTT@ora12c> create table test_im tablespace users as select rownum id,systimestamp time from dual connect by level <=100000;


Table created.


SCOTT@ora12c> alter table test_im inmemory;


Table altered.


SCOTT@ora12c> exec DBMS_INMEMORY.POPULATE('SCOTT','TEST_IM');


PL/SQL procedure successfully completed.


SCOTT@ora12c> select SEGMENT_NAME,INMEMORY_SIZE,BYTES,POPULATE_STATUS from v$im_segments where segment_name='TEST_IM';


SEGMENT_NAME

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

INMEMORY_SIZE  BYTES POPULATE_

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

TEST_IM

2228224  3145728 COMPLETED

可见,TEST_IM原始大小为3.1M,存入IM中为2.2M。


使用内存空间如下:

SCOTT@ora12c> select * from v$inmemory_area;


POOL  ALLOC_BYTES USED_BYTES POPULATE_STATUS

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

CON_ID

----------

1MB POOL  418381824  2097152 DONE

 1


64KB POOL  88080384  131072 DONE

 1



查看当前session的与IM相关的一些统计信息:

SCOTT@ora12c> select name,value from v$mystat, v$statname

where v$mystat.statistic# = v$statname.statistic#

and v$statname.name in

('IM transactions',

'IM transactions rows journaled',

'IM space private journal extents allocated',

'IM space private journal segments allocated',

'IM scan CUs memcompress for query low',

'IM scan CUs split pieces'

);


NAME  VALUE

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

IM transactions   0

IM transactions rows journaled  0

IM space private journal extents allocated  0

IM space private journal segments allocated  0

IM scan CUs memcompress for query low  0

IM scan CUs split pieces  0


6 rows selected.


恩,当前都为0。然后我们修改一些数据,但是不提交:


SCOTT@ora12c> update test_im set time=systimestamp where mod(id,50)=1;


2000 rows updated.


SCOTT@ora12c> select name,value from v$mystat, v$statname

where v$mystat.statistic# = v$statname.statistic#

and v$statname.name in

('IM transactions',

'IM transactions rows journaled',

'IM space private journal extents allocated',

'IM space private journal segments allocated',

'IM scan CUs memcompress for query low',

'IM scan CUs split pieces'

);


NAME  VALUE

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

IM transactions   1

IM transactions rows journaled  2000

IM space private journal extents allocated  51

IM space private journal segments allocated  1

IM scan CUs memcompress for query low  1

IM scan CUs split pieces  1


6 rows selected.


统计信息变了,注意蓝色字体的部分。我们修改了2000行数据,IM事务日志也记录了这些信息。使用了51个extent。再次查看下当前的IM内存使用状况:


SCOTT@ora12c> select * from v$inmemory_area;


POOL  ALLOC_BYTES USED_BYTES POPULATE_STATUS

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

CON_ID

----------

1MB POOL  418381824  2097152 DONE

 1


64KB POOL  88080384  3538944 DONE

 1

可以看到,1M的pool值没有变化,64k的pool发生了变化,具体为3538944-131072 =3407872=(51+1)*64k

看上面的统计信息,使用的64k pool为51个。但是这块计算出现了1的偏差。可能是还存了其他一些元数据。


然后我们提交修改,再查看统计信息变化:


SCOTT@ora12c> commit;


Commit complete.


SCOTT@ora12c> select name,value from v$mystat, v$statname

where v$mystat.statistic# = v$statname.statistic#

and v$statname.name in

('IM transactions',

'IM transactions rows journaled',

'IM space private journal extents allocated',

'IM space private journal segments allocated',

'IM scan CUs memcompress for query low',

'IM scan CUs split pieces',

'IM space private journal extents freed',

'IM space private journal bytes freed',

'IM repopulate CUs requested'

); 2 3 4 5 6 7 8 9 10 11 12 13


NAME  VALUE

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

IM transactions   1

IM transactions rows journaled  2000

IM space private journal extents allocated  51

IM space private journal extents freed  51

IM space private journal bytes freed  3342336

IM space private journal segments allocated  1

IM repopulate CUs requested  0

IM scan CUs memcompress for query low  1

IM scan CUs split pieces  1


9 rows selected.


注意蓝色字体部分,可以看到原来记录这些数据变化的事务日志空间已经被free了。查看下IM内存状况,也可以确认这一点:

SCOTT@ora12c> select * from v$inmemory_area;


POOL  ALLOC_BYTES USED_BYTES POPULATE_STATUS

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

CON_ID

----------

1MB POOL  418381824  2097152 DONE

 1


64KB POOL  88080384  131072 DONE

 1


又回到了初始值。


注意上面统计信息中的:IM repopulate CUs requested 部分,我们这里显示为0。也就是说,我们修改数据并提交的时候,并没有触发repopulation。但是如果事务中修改的数据量或者数据比例过大,导致太多的记录stale的话,则有可能触发repopulation。


另外,启用IM选项之后,对表的修改操作,其耗时也会下降,也就是说,对dml操作,IM也是可以有加速效果的。

以下所有均为我们的专职老师原创,转载请注明出处

上一篇 Oracle Database 12C 之In-Memory(十一)

下一篇 Oracle Database 12C 之In-Memory(十三)