12 C in-memory option

Size: px

Start display at page:

Download "12 C in-memory option"

难江
6 years ago
Views:

2 揭秘 12C In-Memory Option 魏兴华 shoug.info 上海 Oracle 用户组

3 Abort Me 8 年 Oracle 使用经验 ITPUB 认证博客专家 ACOUG 核心成员 SHOUG 核心成员 ORACLE ACE-A 擅长领域 :SQL 调优性能诊断故障恢复曾就职于东软集团 Alibaba 集团, 现任沃趣科技高级技术专家微博 : 魏兴华 -DBA 公司主页 : weixinghuayuanfen@126.com BLOG:

4 Agenda 1 列存及其优势 2 In-Memory Storage Index 3 Compression 4 SIMD 5 In-Memory on RAC

5 In-Memory 的威力不到一秒处理完成这不是全部, 这里只发挥了列存的优势

6 In-Memory 的威力列存只是 In- Memory 的秘诀之一, 存储索引 SIMD 更是制胜法宝

7 行格式 vs 列格式存储格式决定了 : 行格式适用于处理少量行多数列, 列格式适用于处理少量列, 大量行 Select *from Sales where customer_id=xx 行数据连续存放在一起 Select sum(price) from orders 列数据连续存放在一起

读取不同位置列数据需要的时间 select count($column) from big_table; 7 6 5 4 3 2 1 0

8 读取不同位置列数据需要的时间 select count($column) from big_table; 行格式的数据越靠后的列读取越慢, 列格式的数据读取时间与列的位置无关, 与数据类型和长度有关读取不同位置列时间趋势 BUFFER_CACHE IM

9 行列,Oracle 如何选一致性? 交易分析行格式

10 In-Memory Column Store SGA 的新组件 ( 不在 Buffer_Cache 中 ) 由参数 inmemory_size 控制, 最小值 100M 静态池, 非 Lru 算法, 用户决定放哪些对象进去放进去的对象不会被自动 age out, 除非用户手工干预或者系统重启

11 In-Memory Area: 组成包含两个子池 - In memory compression units(imcus) -Snapshot Metadata Units(SMUs) IMCUs 包含列格式的数据 SMUs 包含元数据和事务信息通过 V$INMEMORY_AREA 视图可以查看 2 个子池的状态和相关信息

12 IM Column Unit 数据段, 包含三列 :C1,C2,C3 IM Column Unit 可变大小

13 Question 由于要维护 In-Memory Area 区和 Buffer Cache 的一致性, 所以放入 IM 区的表上的 DML 操作会变慢?

14 Populating The In-Memory Column Store INMEMORY 属性可以作用的对象 : 表 / 分区 ( 字段级别 ), 不包含索引表空间物化视图 ( 字段级别 ) 例如 : ALTER TABLESPACE ts_data INMEMORY; ALTER TABLE sales INMEMORY NO INMEMORY(prod_id); ALTER TABLE test INMEMORY INMEMORY(object_name); ALTER TABLE sales MODIFY PARTITION SALES_Q1_1998 NO INMEMORY;

15 Populate 由 worker processes(ora_w001_xxxx) 完成不做排序处理 ( 对压缩不友好 ) Poplulate 过程中数据库表空间表可以访问 In-Memory Compression Units( 可变大小 ) 在数据库启动或表被访问时触发 Populate 当前版本 ( ) 基于索引的访问还不能触发 populate, 需要全表扫描触发

16 Populate Priority 默认级别, 数据库启动后不会自动加载, 需要首次全表访问后触发

17 Restrictions Sys 用户或 system sysaux 表空间的对象不能被放入 In-Memory, 可以通过 _enable_imc_sys 隐含参数开启索引组织表 Clustered 表表小于 64K 不能在 Active Data Guard 上使用以下数据类型不能支持 : LONGS (deprecated since Oracle Database 8i) Out of line LOBS

18 Compression 可以让更多数据放入 IM 的秘诀, 对于性能提升帮助不大

19 压缩比例压缩比例取决于列的临近值是否重复压缩算法字段类型 Case 1: 基于 dba_objects 表创建的 test 4,837 M 默认算法压缩后 628M, 压缩比 7 倍 Case 2: 每个列都基于序列创建的表 test, 无重复 5352M 默认算法压缩后 9276M, 对于无重复值的列, 压缩后占用的空间会更大

Compression: 读取无需解压表实际大小 4837M, 基于 dba_object 压缩算法压缩后大小压缩比例 Cpu_time QUERY LOW 628M 7.

20 Compression: 读取无需解压表实际大小 4837M, 基于 dba_object 压缩算法压缩后大小压缩比例 Cpu_time QUERY LOW 628M QUERY HIGH 514M capacity low 386M capacity high 231M

21 Compression 读取无需解压表 compress_table 物理大小 1.7G, 默认压缩算法放入 In-Memory 449M, 不压缩放入 In- Memory 1.8G. 两种方式的读取时间相差无几, 默认的压缩算法压缩后对查询性能无影响

22 In-Memory Storage Index 很多数据库中已经存在变得越来越主流与 Exadata 的 storage indexes 非常相像每个在 IM Column Store 里的列的 storage indexes 被自动维护和创建他们只存储在内存中自动跟踪每个 IMCU 中的列的最大值最小值 ( 有代价 ) 并不能精确的对记录进行定位, 开发出来的目的是为了过滤掉不包含相关数据的 IMCU

23 In-Memory Storage Index

24 In-Memory Storage Index execute snap_stats.start_snap select count(*) from test where object_id=1; execute snap_stats.end_snap 不需要访问任何 IMcu

25 In-Memory Storage Index 选取了列一上的存储索引记录, 经过排序后的字段能充分的利用存储索引的优势, 消减读取的 IMcu 数基于序列和时间的字段能充分利用存储索引

26 SIMD Vector Processing Each CPU core scans local inmemory columns Scans use super fast SIMD vector instructions Originally designed for graphics & science Billions of rows/sec scan rate per CPU core -ROW format is millions/sec

27 In-Memory Joins IM 虽然很快, 但是 HASH JOIN 很慢, 怎么办?

28 In-Memory Joins: 布隆过滤一个比 ORACLE 的存在还要早的技术,1970 年在并行执行计划中的使用非常普遍, 只能用于 HASH JOIN 场景 11.2 版本开始, 串行执行的 sql 也可以使用布隆过滤. 布隆过滤是一种内存数据结构, 用于判断某个元素是否属于一个集合. 布隆过滤的优势在于使用的很少内存, 就可以过滤大部分的数据

29 In-Memory Joins 执行方式执行时间 Inmemroy_bloom_filter 0.78s Inmemroy_no_bloom_filter 4.59s Buffer_cache 5.50s HASH JOIN 过程本身并没有做优化, ORACLE 吹牛了

30 In-Memory Joins

31 The In-Memory Column Store On RAC 要开启 automatic DOP, 并行度要大于节点数 Shared nothing 分区表默认按照分区来在节点间做分布如果分区都数据量有倾斜, 可以指定 rowid 来做数据分布

32 The In-Memory Column Store On RAC RAC 环境下, 如果要使用 IM 性能, 需要设置 parallel_degree_policy 为 auto, 否则优化器会感知不到全局 IM 的情况是否真的发生了 IM ACCESS 要通过统计信息确定

33 The In-Memory Column Store On RAC 设置为自动并行策略后, 优化器意识到了全局的 IM, 采用了并行的执行计划, 执行时间也大大缩短

34 In-Memory Aggregation

35 Bulk Data Loads Insert /*+ append */ Commit 后, IM 会感知到有未 poplulate 的数据, 需要全表扫描触发才会重新对未 poplulate 的字节做 Load

36 Partition Exchange Loads

37 Transaction Processing 变更日志, 跟踪变化的记录, 会有进程定期 merge 这些变化的记录对于 DML 操作频繁的表不适合放在 IM 中, 增加了维护一致性的开销

38 不同读取模式对资源的消耗 SQL 语句 Cpu_time Elapsed_time Buffer_gets select /*+ inmemory */count(*) from test ( 无意义 ) select /*+ buffer_cache */ count(*) from tes select /*+ dierct path */ count(*) from test select /*+ scatter */ count(*) from test In-memory 读取方式比 buffer_cache 快 4 倍, 但这不是所有的事实

39 Case 1:Consistent gets create table read_consis inmemory no memcompress as select * from dba_objects; select count(*) from read_consis where object_name= test ; 读取段头块的次数, 不包含 IMcu 的个数

40 Case 2:Read Consistency update read_consis set object_name= XXX where rownum<3; select count(*) from read_consis where object_name= test ;

41 Case 3: 度量资源消耗

42 Case 3: 度量资源消耗

43 Case 3: 度量资源消耗

44 Case 4:in-memory Bug

45 Case 4:in-memory Bug CBO 会计算 IM 的成本和 NO-IM 路径的成本, 但是优化器不知表是否已经 Populate 到 IM 中, 应该是优化器的一个 BUG

46 Case 5: 读取时间比对不同读取模式对资源的消耗 scatter read direct_path buffer_cache in-memory

47 QA AUTODOP ON RAC WITH IMC IN DISTRIBUTE MODE SHOULD BE ROUNDED TO # OF INSTANCES CHECK FOR EXPENSIVE PARALLEL OPERATIONS NEEDS TO BE OVERRIDDEN FOR IMC

Oracle 4

Oracle 4 01 04 Oracle 07 Oracle Oracle Instance Oracle Instance Oracle Instance Oracle Database Oracle Database Instance Parameter File Pfile Instance Instance Instance Instance Oracle Instance System