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
  • 浏览次数:
  • 413
  • 分享


最后一个问题。IM中存储了对象的数据和元数据,以及发生在这些对象上的事务日志。那如果存储了该对象之后,剩余的空间无法完成记录这些事务日志,那又会怎样?

来看例子:

SCOTT@ora12c> create table test_im (id number, TIME TIMESTAMP) tablespace users;


Table created.


SCOTT@ora12c> begin

for i in 1..20 loop

insert into test_im select rownum+200000*(i-1) id,systimestamp time from dual connect by level <=200000;

commit;

end loop;

end;

/


PL/SQL procedure successfully completed.


创建测试表。

SCOTT@ora12c> alter table test_im inmemory;


Table altered.


SCOTT@ora12c> exec dbms_inmemory.populate('SCOTT','TEST_IM');


PL/SQL procedure successfully completed.

将该表缓存到IM中。


此时内存使用情况如下:


SCOTT@ora12c> select * from v$inmemory_area;


POOL  ALLOC_BYTES USED_BYTES POPULATE_STATUS

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

CON_ID

----------

1MB POOL  82837504  71303168 DONE

 1


64KB POOL  4194304  524288 DONE

 1


SCOTT@ora12c> select OWNER,SEGMENT_NAME,INMEMORY_SIZE,BYTES,POPULATE_STATUS from v$im_segments;


OWNER

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

SEGMENT_NAME

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

INMEMORY_SIZE  BYTES POPULATE_

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

SCOTT

TEST_IM

65536000 109051904 COMPLETED



测试一下:

SCOTT@ora12c> set autot on stat;

SCOTT@ora12c> set timing on;

SCOTT@ora12c> select count(*) from test_im;

SCOTT@ora12c> select count(*) from test_im;


COUNT(*)

----------

4000000


Elapsed: 00:00:00.10


Statistics

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

 38 recursive calls

 0 db block gets

144 consistent gets

 0 physical reads

 0 redo size

542 bytes sent via SQL*Net to client

551 bytes received via SQL*Net from client

 2 SQL*Net roundtrips to/from client

 4 sorts (memory)

 0 sorts (disk)

 1 rows processed


走一次全表扫描,注意执行时间和consistent gets。

查看下当前的统计信息:


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 repopulate CUs requested',

'IM transactions CUs invalid',

'IM transactions downgrade mode'

);


NAME  VALUE

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

IM transactions   0

IM transactions downgrade mode  0

IM transactions CUs invalid  0

IM repopulate CUs requested  0


接下来,做一个数据修改:


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


133334 rows updated.


Elapsed: 00:00:02.82


再看统计信息:

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 repopulate CUs requested',

'IM transactions CUs invalid',

'IM transactions downgrade mode'

); 2 3 4 5 6 7 8


NAME  VALUE

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

IM transactions   1

IM transactions downgrade mode  1

IM transactions CUs invalid  5

IM repopulate CUs requested  7


当前IM大小设置为100m,在执行update操作之前,已经使用了将近72M。再加上这些修改操作生成的日志,妥妥的是存不下的。于是出现了downgrade mode相关的统计信息:该值不为0。


同时由于IM内存不够用,也使得部分IMCU出现了invalid状态,也就是说IM中的数据和db buffer cache中的数据不一致了,那就需要repopulate了,参见上述统计信息的最后两行,也就是红色字体部分。


这时候再执行全表扫描看看:


SCOTT@ora12c> set autot on stat;

SCOTT@ora12c> select count(*) from test_im;


COUNT(*)

----------

4000000


Elapsed: 00:00:00.11


Statistics

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

 0 recursive calls

 0 db block gets

12659 consistent gets

 0 physical reads

 0 redo size

542 bytes sent via SQL*Net to client

551 bytes received via SQL*Net from client

 2 SQL*Net roundtrips to/from client

 0 sorts (memory)

 0 sorts (disk)

 1 rows processed


与原来的全表扫描相比,执行时间相差不大,但是统计信息,尤其是consistent gets猛增到了12659,而原来是144······


重新查看当前IM使用情况:

SCOTT@ora12c> select * from v$inmemory_area;


POOL  ALLOC_BYTES USED_BYTES POPULATE_STATUS

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

CON_ID

----------

1MB POOL  82837504  70254592 DONE

 1


64KB POOL  4194304  524288 DONE

 1


可见,都又回到了初始值。

oracle在当IM中的区域无法满足其列对象的事务日志存储要求的时候,就会出现downgrade mode,从而从IM中释放相关事务生成的日志,转而用传统的方式来完成事务处理。

当出现这种情况时,不仅DML操作性能会下降,随之的select操作,性能也会受到影响。



ok,至此,IM系列全部完结。当然,这一部分还有东西,但是这里就不再写了,各位小伙伴可以自己去慢慢研究了。



昔日有孙武精于兵道,而成孙子兵法一十三篇,而今,我照虎画猫,也来了个oracle IM一十三篇。虽未敢斗胆与往者前贤相比,但技术之路,道阻且艰,唯有心怀谦逊,继续向前而已。

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

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

下一篇 静态路由和以太网接口