Oracle 12C In-Memory特性研究
一、Oracle In-Memory
行格式与列格式:
Oracle 数据库传统上以行格式存储数据。在行格式数据库中,数据库中存储的每个新事务或新记录都表示为表中的一个新行,而在查询数据时是利用传统BUFFER CACHE。
列格式数据库将表以单独的列结构存储到内存中。列格式适用于报表类,分析,选择少量列但是查询要访问大部分的数据的场景。
启用IMO非常简单,12.1.0.2及之后版本下,设置INMEMORY_SIZE 为非0值便可启用IM column store特性。
INMEMORY_SIZE 是个实例级参数,默认为0,设置一个非0值时,最小值为100M。
通常情况下,sys用户下的对象及SYSTEM、SYSAUX表空间上的对象无法使用IMO特性,但通过设置“_enable_imc_sys”隐含参数也可以使用
开启DB In-Memory过程如下:
1、修改INMEMORY_SIZE参数:
SQL> ALTER SYSTEM SET INMEMORY_SIZE=1G SCOPE=SPFILE;
2、检查sga参数的设置,确保在设置完inmemroy_size参数之后数据库实例还可以正常启动。如果数据库使用了ASMM,则需要检查sga_target参数。如果使用了AMM,则需要检查MEMORY_TARGET参数,同时也需要检查SGA_MAX_TARGET(或MEMORY_MAX_TARGET)。
备注:从 12.2 开始,可以动态增加 In-Memory 区域的大小,为此,只需 通过 ALTER SYSTEM 命令增加 INMEMORY_SIZE 参数值即可
3、重启数据库实例
4、查看IM特性是否开启
SQL> SHOW PARAMETER inmemory;
NAME TYPE VALUE
———————————— ———– ——————————
inmemory_adg_enabled boolean TRUE
inmemory_clause_default string
inmemory_expressions_usage string ENABLE
inmemory_force string DEFAULT
inmemory_max_populate_servers integer 2
inmemory_query string ENABLE
inmemory_size big integer 1G
inmemory_trickle_repopulate_servers_ integer 1
percent
inmemory_virtual_columns string MANUAL
optimizer_inmemory_aware boolean TRUE
1234567891011121314
1.2 开启与关闭IM column store
1、TABLE 级启用:
可以通过如下初始建表或后续修改表 inmemory 属性的方式进行启用:
create table test (id number) inmemory;
alter table test inmemory;
123
2、COLUMN 级启用:
仅启用表中某列前,该表必须先设置为 inmemory 模式:
alter table imo_t1 inmemory (id) no inmemory (name,type); alter table imo_t2 inmemory (name) no inmemory (id,type);
TABLE_NAME SEG_COL_ID COLUMN_NAME INMEMORY_COMPRESSION
———- ———- ————— ———————–
IMO_T1 1 ID DEFAULT
IMO_T1 2 NAME NO INMEMORY
IMO_T1 3 TYPE NO INMEMORY
IMO_T2 1 ID NO INMEMORY
IMO_T2 2 NAME DEFAULT
IMO_T2 3 TYPE NO INMEMORY
1234567891011121314
3、表空间级启用:
可以通过如下初始创建表空间或后续修改表空间 inmemory 属性的方式进行启用,在属性为 inmemory 的表空间中创建的对象自动加载 inmemory 属性,除非显示设置对象为 no inmemory:
create tablespace imotest datafile ‘/u01/app/oracle/oradata/orcl/imotest01.dbf’ size 100M default inmemory;
alter tablespace imotest default inmemory;
select tablespace_name, def_inmemory from dba_tablespaces where tablespace in (‘IMOTEST’);
—————————— —————
IMOTEST ENABLED
12345678910
4、如果需要知道具体哪些列开启了IM column store则需要到V$IM_COLUMN_LEVEL中进行查看
SQL> SELECT TABLE_NAME, COLUMN_NAME, INMEMORY_COMPRESSION FROM V$IM_COLUMN_LEVEL WHERE TABLE_NAME = ‘TBNAME’;
1
5、查询有关IM列表属性
SQL> SELECT OWNER, SEGMENT_NAME,bytes,INMEMORY_SIZE,POPULATE_STATUS, BYTES_NOT_POPULATED FROM V$IM_SEGMENTS;
———- ———- ———- ————- ————- ——————-
CS MEM 391880704 52428800 COMPLETED 0
CS TEST 99426304 15138816 COMPLETED 0
CS DUP 5095424 3407872 COMPLETED 0
1234567
6、关闭inmemory
alter table test no inmemory;
1
1.3 inmemory优先级调整
启用了 IMO 的对象,会按照一定的优先级进入 SGA 中配置好的 IN-MEMORY 区域,同时,在 IN-MEMORY 区域用满后,依次置换出优先级较低的对象。下表为关于 IMO 对象优先级说明:
优先级描述
PRIORITY NONE 缺省级别;执行 SQL 引起对象扫描后,触发进入 IN-MEMORY
PRIORITY CRITICAL 最高优先级;数据库启动后立即进入 IN-MEMORY
PRIORITY HIGH 在具有 CRITICAL 优先级的对象之后进入 IN-MEMORY
PRIORITY MEDIUM 在具有 CRITICAL、HIGH 优先级的对象之后进入 IN-MEMORY
PRIORITY LOW 在具有 CRITICAL、HIGH、MEDIUM 优先级的对象之后进入 IN-MEMORY
12345
修改示例:
SQL> alter table test inmemory priority high;
FROM USER_TABLES WHERE TABLE_NAME = ‘TEST’;
INMEMORY INMEMORY INMEMORY_COMPRESS INMEMORY_DISTRI INMEMORY_DUPL
——– ——– —————– ————— ————-
ENABLED HIGH FOR QUERY LOW AUTO NO DUPLICATE
1234567891011
1.4 加载对象到IM
1、通过全表扫描objects加载数据到IM
SQL> SELECT /*+ FULL (s) */ COUNT(*) FROM table s;
查询V$IM_SEGMENTS中的数据
SQL> col owner for a10
OWNER SEGMENT_NA POPULATE_ BYTES_NOT_POPULATED
12345678910111213
2、DBMS_INMEMORY来加载数据
DBMS_INMEMORY包提供了两个PROCEDURE来手工加载数据到IM中:
POPULATE:强制加载给定的表
REPOPULATE:强制重新加载给定的表,在该表已经至少加载过一次之后才可使用。
手工执行DBMS_INMEMORY.POPULATE procedure来加载TEST表到IM中
SQL> EXEC DBMS_INMEMORY.POPULATE(‘CS’,’TEST’);
12
通过DBMS_INMEMORY.REPOPULATE prcedure及FORCE=>TRUE选项来加载TEST表到IM中。FORCE=>TRUE选项强制进行一次完整重新载入,类似于full refresh
SQL> EXEC DBMS_INMEMORY.REPOPULATE(‘CS’,’TEST’, FORCE=>TRUE);
1
3、设置PRIORITY clause自动加载数据
将测试表TEST的PRIORITY级别改为HIGH。
SQL> ALTER TABLE test INMEMORY PRIORITY HIGH|MEDIUM|LOW;
1
二、In-Memory测试
2.1 全字段查询
通过CTAS方式创建表TEST,普通行式扫描与开启inmemory特性分别测试,比对执行计划。
create table test as select * from dba_objects;
1
no inmemory查询测试
set timing on
set autotrace traceonly
set pagesize 200 linesize 200
col TABLE_NAME for a20
col INMEMORY_PRIORITY for a20
col INMEMORY_DISTRIBUTE for a20
col INMEMORY_COMPRESSION for a20
1234567
全字段查询,执行计划
SQL> select count(*) from test;
COUNT(*)
———-
74329
Elapsed: 00:00:00.01
———————————————————-
Plan hash value: 1950795681
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
——————————————————————-
| 0 | SELECT STATEMENT | | 1 | 403 (1)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS FULL| TEST | 74329 | 403 (1)| 00:00:01 |
——————————————————————-
Statistics
———————————————————-
0 recursive calls
5 db block gets
1460 consistent gets
0 physical reads
0 redo size
544 bytes sent via SQL*Net to client
608 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
1234567891011121314151617181920212223242526272829303132
开启in memory查询测试
SQL> alter table test inmemory;
1
SQL> select TABLE_NAME,INMEMORY_PRIORITY,INMEMORY_DISTRIBUTE,INMEMORY_COMPRESSION from user_tables;
——————– ——————– ——————– ——————–
TEST NONE AUTO FOR QUERY LOW
1234567
SQL> select pool,ALLOC_BYTES/1024/1024,USED_BYTES/1024/1024,POPULATE_STATUS,con_id
from V$INMEMORY_AREA;
———— ———— ——————— ———- ——————
1MB POOL 815 0 DONE 3
64KB POOL 192 0 DONE 3
–因为只是把该表设置了INMEMORY,但是未查询过,所以查询V$INMEMORY_AREA中未使用相关内存–
12345678
全字段查询,执行计划
第一次执行:
SQL> select count(*) from test;
———-
74329
———————————————————-
Plan hash value: 1950795681
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
—————————————————————————-
| 0 | SELECT STATEMENT | | 1 | 403 (1)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS INMEMORY FULL| TEST | 74329 | 403 (1)| 00:00:01 |
—————————————————————————-
Statistics
———————————————————-
5 recursive calls
5 db block gets
1467 consistent gets
0 physical reads
0 redo size
544 bytes sent via SQL*Net to client
608 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
2 sorts (memory)
0 sorts (disk)
1 rows processed
12345678910111213141516171819202122232425262728293031323334
第二次执行:
Elapsed: 00:00:00.03
———————————————————-
Plan hash value: 1950795681
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
—————————————————————————-
| 0 | SELECT STATEMENT | | 1 | 16 (7)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS INMEMORY FULL| TEST | 74329 | 16 (7)| 00:00:01 |
—————————————————————————-
Statistics
———————————————————-
0 recursive calls
3 db block gets
9 consistent gets
0 physical reads
0 redo size
544 bytes sent via SQL*Net to client
608 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
12345678910111213141516171819202122232425262728
查询inmemory内存使用:
SQL> select pool,ALLOC_BYTES/1024/1024,USED_BYTES/1024/1024,POPULATE_STATUS,con_id
from V$INMEMORY_AREA;
————————– ——————— ——————– ————————– ———-
1MB POOL 815 4 DONE 3
64KB POOL 192 .25 DONE 3
–再次查看,已经使用了分配的In-Memory中内存
12345678
性能比对:
sql plan
no-inmemory
inmemory
consistent gets
1460
9
physical reads
0
0
Cost
403
16
结果:
开启inmemory之后性能提升162倍
2.2 索引字段比较测试
在已开启IMO特性条件下,通过给表test增加列索引,比较IM与索引执行计划
1、在object_name上创建索引
SQL> create index idx_test_OBname on test(OBJECT_NAME);
1
2、查看表TEST是否加载到IM中
col owner for a20
col SEGMENT_NAME for a20
col POPULATE_STATUS for a20
col BYTES_NOT_POPULATED for 99999
OWNER SEGMENT_NAME POPULATE_STATUS BYTES_NOT_POPULATED
——————– ——————– ——————– ——————-
CS TEST COMPLETED 0
表已被加入到IM中
12345678910
3、使用索引简单列查询
SQL> set autotrace traceonly
SQL> select count(*) from test where object_name=’TEST’;
Execution Plan
———————————————————-
Plan hash value: 3197243274
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
————————————————————————————-
| 0 | SELECT STATEMENT | | 1 | 35 | 3 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 35 | | |
|* 2 | INDEX RANGE SCAN| IDX_TEST_OBNAME | 10 | 350 | 3 (0)| 00:00:01 |
————————————————————————————-
—————————————————
Statistics
———————————————————-
2 recursive calls
0 db block gets
6 consistent gets
2 physical reads
0 redo size
542 bytes sent via SQL*Net to client
607 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
逻辑读:6
物理:2
1234567891011121314151617181920212223242526272829303132333435363738
4、强制全表扫描查询
SQL> select /*+full(s)*/count(*) from test s where object_name=’test’;
———————————————————-
Plan hash value: 1950795681
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
————————————————————————————
| 0 | SELECT STATEMENT | | 1 | 35 | 124 (1)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 35 | | |
|* 2 | TABLE ACCESS INMEMORY FULL| TEST | 9 | 315 | 124 (1)| 00:00:01 |
————————————————————————————
—————————————————
filter(“OBJECT_NAME”=’test’)
Statistics
———————————————————-
1 recursive calls
0 db block gets
10 consistent gets
0 physical reads
0 redo size
541 bytes sent via SQL*Net to client
607 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
逻辑读:10
物理读:0
12345678910111213141516171819202122232425262728293031323334353637
总结:在数据离散度较高,且通过索引条件过滤的扫描场景中,IM特性对性能并没有提升,传统的索引+行式存储的执行计划已经足够,在默认情况下还是会根据查询索引返回rowid的方式查找数据。
2.3 批量update测试
1、创建测试表disk、emp,分别为im表以及rows表,总数相同
SQL> create table disk as select * from dba_objects;
SQL> insert into disk select * from disk;
———-
2379520
SQL> create table mem as select * from disk inmemory;
1234567891011121314151617181920212223242526272829303132
更新磁盘表
update disk set owner=‘tom’;
更新内存表
update mem set owner=‘tom’;
普通表:
时间:14.49
逻辑读:3202294+894128
物理读:5602
cost:403
IM表:
时间:18.94
逻辑读:3231179+254
物理读:92476
cost:483
总结:IM特性在update性能有所下降
2.4 大批量insert测试
从磁盘插到磁盘
insert into disk select * from cs;
从磁盘插到内存
insert into mem select * from cs;
普通表:
时间:0.13
逻辑读:9332+2903
物理读:2895
cost:404
IM表:
时间:0.17
逻辑读:3231179+254
物理读:92476
cost:483
2.5 大量delete测试
delete from disk where rownum <10000;
delete from mem where rownum <10000;
普通表:
时间:0.08
逻辑读:11470+202
物理读:253
cost:12986
IM表:
时间:0.07
逻辑读:11472+9
物理读:0
cost:493
2.6 压缩方式测试
压缩方式
描述
NO MEMCOMPRESS
IMO 中存储无压缩
MEMCOMPRESS FOR DML
最小化压缩,优化 DML 操作
MEMCOMPRESS FOR QUERY LOW
缺省方式:查询性能最优、空间压缩效果好于DML方式
MEMCOMPRESS FOR QUERY HIGH
查询性能次优(excellent)、空间压缩效果好于 QUERY LOW
MEMCOMPRESS FOR CAPACITY LOW
查询性能良好(good)、空间压缩效果好于 QUERY HIGH
MEMCOMPRESS FOR CAPACITY HIGH
缺省设置、空间压缩效果最优
查看压缩比
col owner for a5
col SEGMENT_NAME for a10
col POPULATE_STATUS for a10
col INMEMORY_COMPRESSION for a10
SQL> SELECT V.OWNER, V.SEGMENT_NAME,V.BYTES/1024/1024 ORIG_SIZE_MB,V.INMEMORY_SIZE/1024/1024 IN_MEM_SIZE_MB,BYTES_NOT_POPULATED,POPULATE_STATUS status,INMEMORY_COMPRESSION,V.BYTES/V.INMEMORY_SIZE COMP_RATIO FROM V$IM_SEGMENTS V WHERE SEGMENT_NAME = ‘TEST’;
—– ——————– ———— ————– ——————- ——————– —————– ———-
CS TEST 1466.78125 110.625 0 COMPLETED FOR QUERY LOW 13.2590395
123456789
表TEST在磁盘上占用1466MB,采用默认压缩方式,内存中占用110.625MB,压缩比为13.26:1
压缩比测试:
表TEST大小1466.78125MB,数据行9514112
1、NO MEMCOMPRESS:
alter table test inmemory MEMCOMPRESS NO MEMCOMPRESS;
逻辑读:14
物理读:0
COST: 126
时间: 0.01
压缩比:1.19
123456
2、MEMCOMPRESS FOR DML:
alter table test inmemory MEMCOMPRESS FOR DML;
逻辑读:14
物理读:0
COST: 126
时间:0.01
压缩比:1.22
123456
3、MEMCOMPRESS FOR QUERY LOW:
alter table test inmemory MEMCOMPRESS FOR QUERY LOW;
逻辑读:14
物理读:0
COST:125
时间:0.01
压缩比:7.20
123456
4、MEMCOMPRESS FOR QUERY HIGH:
alter table test inmemory MEMCOMPRESS FOR QUERY high;
逻辑读:14
物理读:0
COST: 125
时间:0.01
压缩比:9.67
123456
5、MEMCOMPRESS FOR CAPACITY LOW:
alter table test inmemory MEMCOMPRESS FOR CAPACITY LOW;
逻辑读:14
物理读:0
COST: 125
时间:0.01
压缩比:12.91
123456
6、MEMCOMPRESS FOR CAPACITY HIGH:
alter table test inmemory MEMCOMPRESS FOR CAPACITY HIGH;
逻辑读:14
物理读:0
COST: 25
时间:0.01
压缩比:19.14
测试结果汇总:
压缩方式
压缩比
NO MEMCOMPRESS
1.19
MEMCOMPRESS FOR DML
1.22
MEMCOMPRESS FOR QUERY LOW
7.20
MEMCOMPRESS FOR QUERY HIGH
9.67
MEMCOMPRESS FOR CAPACITY LOW
12.91
MEMCOMPRESS FOR CAPACITY HIGH
19.14
总结:压缩方式不同,表加载到IM中的时间也会不一样。压缩比越大加载到内存中的时间越长。而对于select查询消耗时间不影响。
2.7 查询大量列性能测试
三、评估对象在IMO大小
DBMS_COMPRESSION.GET_COMPRESSION_RATIO
在对一张表使用COMPRESSION clause进行IM压缩级别设置之前,我们可以通过Oracle的COMPRESSION ADVISOR对表放入到IM中的大小进行提前计算。
SET SERVEROUTPUT ON
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253
Comp. ratio (QUERY LOW):7
估计结果压缩比7,实际压缩比为7.20
#五、RAC环境测试
rac环境独有参数DUPLICATE clause、DISTRIBUTE clause:
DUPLICATE clause:
此参数为EXADATA一体机专用,在RAC环境中,每个节点拥有自己的IM Area。一个objects根据DUPLICATE clause的设置将一样的数据加载到多个IM Area中。
默认是NO DUPLICATE设置,表示在数据库的IM中对一个objects在所有节点中合起来只保存一份。举例说明,比如三节点的RAC中,对于分区表SALES来讲可能2012年份的数据在1节点,2013年份的数据在2节点,2014年份的数据在3节点,每个分区只保存在一个节点上。
为了提升可用性,也可以设置为DUPLICAET ALL,在每个节点上都保存一份。举例说明,还是刚才那个SALES表的请款下,1,2,3三个节点各保存一份完整sales表数据到各自的IM中。在任意一个节点上都可以获取查询需要的数据。
在设置为DUPLICATE ALL的情况下
DISTRIBUTE clause:
如果一个objects因为太大无法被加载到一个IM Area中,还可以通过DISTRIBUTE clause的设置将它分成几个数据片分别加载到不同的节点中。
默认情况下DISTRIBUTE clause的默认值为AUTO-DISTRIBUTE,这时候是否将objects分布式分布在不同的节点上由Oracle内部算法决定。这个参数对于单实例没有影响,在RAC环境中,默认存在IM中的表会分布在各个节点之中。
RAC环境并不像单实例一样只需修改表的IM属性即可启用,如果要使用IMO,必须在系统层面修改“并行度策略”为自动。下面对参数“parallel_degree_policy”,分别测试2个场景
1、先查看要测试的表TEST是否已加载到IM STORE
col SEGMENT_NAME for a5
col POPULATE_STATUS for a10
col INMEMORY_DISTRIBUTE for a10
col INMEMORY_DUPLICATE for a20
———- —– ———————– ————— —————————– ———- ——————– ———-
2 TEST 9.125 192 123.53125 AUTO NO DUPLICATE COMPLETED
1 TEST 16.1875 192 66.9140625 AUTO NO DUPLICATE COMPLETED
1234567891011
1、开启AUTO DOP
alter system set parallel_degree_policy=AUTO sid=’*’;
alter system set parallel_force_local=false sid=’*’;
alter system flush buffer_cache;
alter system flush shared_pool;
1234
2、查看执行计划
SQL> select /*+ parallel */count(*) from test;
———-
1455168
Execution Plan
———————————————————-
Plan hash value: 2661943167
| Id | Operation | Name | Rows | Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib |
—————————————————————————————————————–
| 0 | SELECT STATEMENT | | 1 | 9 (0)| 00:00:01 | | | |
| 1 | SORT AGGREGATE | | 1 | | | | | |
| 2 | PX COORDINATOR | | | | | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10000 | 1 | | | Q1,00 | P->S | QC (RAND) |
| 4 | SORT AGGREGATE | | 1 | | | Q1,00 | PCWP | |
| 5 | PX BLOCK ITERATOR | | 90948 | 9 (0)| 00:00:01 | Q1,00 | PCWC | |
| 6 | TABLE ACCESS INMEMORY FULL| TEST | 90948 | 9 (0)| 00:00:01 | Q1,00 | PCWP | |
—————————————————————————————————————–
—–
– automatic DOP: Computed Degree of Parallelism is 2
– parallel scans affinitized for inmemory
Statistics
———————————————————-
232 recursive calls
4 db block gets
163 consistent gets
15 physical reads
0 redo size
545 bytes sent via SQL*Net to client
551 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
16 sorts (memory)
0 sorts (disk)
1 rows processed
123456789101112131415161718192021222324252627282930313233343536373839404142
逻辑读:163
物理读:15
12
3、不使用并行查询查询
SQL> select count(*) from test;
———-
1455168
Execution Plan
———————————————————-
Plan hash value: 1950795681
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
—————————————————————————-
| 0 | SELECT STATEMENT | | 1 | 16 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS INMEMORY FULL| TEST | 90948 | 16 (0)| 00:00:01 |
—————————————————————————-
—–
– automatic DOP: Computed Degree of Parallelism is 1 because of no expensive parallel operation
Statistics
———————————————————-
3 recursive calls
0 db block gets
9081 consistent gets
9077 physical reads
0 redo size
545 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
12345678910111213141516171819202122232425262728293031323334353637
逻辑读:9081
物理读:9077
12
4、关闭AUTO DOP
alter system set parallel_degree_policy=MANUAL sid=’*’;
alter system set parallel_force_local=false sid=’*’;
alter system flush buffer_cache;
alter system flush shared_pool;
1234
5、查看执行计划
SQL> select /*+ parallel */count(*) from test;
———-
1455168
Execution Plan
———————————————————-
Plan hash value: 2661943167
| Id | Operation | Name | Rows | Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib |
—————————————————————————————————————–
| 0 | SELECT STATEMENT | | 1 | 9 (0)| 00:00:01 | | | |
| 1 | SORT AGGREGATE | | 1 | | | | | |
| 2 | PX COORDINATOR | | | | | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10000 | 1 | | | Q1,00 | P->S | QC (RAND) |
| 4 | SORT AGGREGATE | | 1 | | | Q1,00 | PCWP | |
| 5 | PX BLOCK ITERATOR | | 90948 | 9 (0)| 00:00:01 | Q1,00 | PCWC | |
| 6 | TABLE ACCESS INMEMORY FULL| TEST | 90948 | 9 (0)| 00:00:01 | Q1,00 | PCWP | |
—————————————————————————————————————–
—–
– automatic DOP: Computed Degree of Parallelism is 2
– parallel scans affinitized for inmemory
Statistics
———————————————————-
209 recursive calls
4 db block gets
17909 consistent gets
17766 physical reads
0 redo size
545 bytes sent via SQL*Net to client
551 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
16 sorts (memory)
0 sorts (disk)
1 rows processed
123456789101112131415161718192021222324252627282930313233343536373839404142
逻辑读:17909
物理读:17766
12
总结:
1、调整系统参数(parallel_degree_policy)之后,rac环境下的IM列查询大幅降低了逻辑读与物理读。
2、在多实例的并发查询中实例之间传输的并不是IMCU,而是每个节点都会对本节点的数据运行相同的sql语句,之后把自己的结果集发送给发起sql语句的实例,组成最终的结果返回给用户。
parallel_degree_policy
AUTO
MANUAL
逻辑读
163
17909
物理读
15
17766
备注:
在没有显式使用并行sql时,rac环境im全表扫描并没有使用并行。oracle的优化器会通过一系列的计算比较cost。
SQL> select count(*) from test;
执行计划Note
—–
automatic DOP:
Computed Degree of Parallelism is 1 because of no expensive parallel operation
12345
In some cases, even with Auto DOP set correctly, the optimizer may calculate the cost of a serial access to be less than the cost of a parallel access. This has been identified as bug 18960760, and will usually only happen when very smalltables in the IM column store are involved in the query.
来自Oracle Blog
https://blogs.oracle.com/in-memory/oracle-database-in-memory-on-rac-part-i
12
四、参考文献
1、Oracle Database In-Memory on RAC – Part I
https://blogs.oracle.com/in-memory/oracle-database-in-memory-on-rac-part-i
2、Oracle 12c DB In-Memory入门实验手册
https://blog.csdn.net/badly9/article/details/49777993
3、Oracle12c IMO 测试
https://www.jianshu.com/p/966ee0182e1c
4、rac并行查询
http://blog.sina.com.cn/s/blog_74a7d3390102wegl.html
5、Oracle In-Memory白皮书
http://www.oracle.com/technetwork/cn/database/in-memory/overview/twp-oracle-database-in-memory-2245633-zhs.pdf
————————————————
版权声明:本文为CSDN博主「iverycd」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/kiral07/article/details/86768842