[Oracle]In-Memory的Join Group 位于内存的何处?

简介:
In-Memory的Join Group 的数据字典位于内存的何处?

有客户问到,使用Oracle 的In-Memory功能时,如果用到了 Join Group,
那么这些这些Join Group,位于内存的何处?

根据同事的执行结果,整理如下:

1.prepare test env.
create table t1 as select * from dba_tables
create table t2 as select * from dba_tables
create inmemory join group t_join (t2(table_name),t1(table_name)  )
create inmemory join group t_join1 (t2(owner),t1(owner)  )

alter table t1 inmemory
alter table t2 inmemory
alter system set inmemory_size =300M


==run sql
SELECT  t1.owner,t2.table_name
FROM t1  , t2  
WHERE t1.table_name = t2.table_name 

==check gd
SELECT o.object_name Table_Name, c.column_name Column_Name, gd.head_address AS "GD Address"
FROM user_objects o, user_tab_columns c, v$im_segdict gd
WHERE gd.objn = o.object_id
AND o.object_name = c.table_name
AND gd.column_number = c.column_id;


T1 TABLE_NAME 000000008A8B10F0
T2     OWNER 000000008A8310F0


对内存进行Dump:

==dum sga memory
HEAP DUMP heap name="IMCA_RW"  desc=0x60001178                 ***<<<<<heap name , following chunks belong this heap.
extent sz=0x1040 alt=336 het=32767 rec=0 flg=0x2 opc=0
parent=(nil) owner=(nil) nex=(nil) xsz=0x3bfffd0 heap=(nil)
fl2=0xa4, nex=(nil), idx=0, dsxvers=1, dsxflg=0x0
dsx first ext=0x89800030
dsx empty ext bytes=0  subheap rc link=0x898000a0,0x898000a0
pdb id=1, src pdb id=1
EXTENT 0 addr=0x89800030
 Chunk        089800040 sz=      112    perm      "perm       "  alo=112
Dump of memory from 0x0000000089800040 to 0x00000000898000B0
.............
 Chunk        08a7e10d8 sz= 46137368    freeable  "cimadrv    "
Dump of memory from 0x000000008A7E10D8 to 0x000000008D3E10F0   ***<<<<<this chunk cover these two address.

       Repeat 3489 times
08A8B10F0 0A0A0A0A 00011E8E 00000001 00000836  [............6...]
08A8B1100 8A8C10F0 00000000 00000000 00000000  [................]
08A8B1110 00000000 00000000 00000000 00000000  [................]

       Repeat 3489 times
08A8310F0 0A0A0A0A 00011E8F 00000000 00000014  [................]
08A831100 8A8410F0 00000000 00000000 00000000  [................]
08A831110 00000000 00000000 00000000 00000000  [................] 

可以得出结论,位于 内存的 in memory 的clumn store里。








本文转自健哥的数据花园博客园博客,原文链接:http://www.cnblogs.com/gaojian/p/7610707.html,如需转载请自行联系原作者

目录
相关文章
|
7月前
|
SQL Oracle 关系型数据库
避坑,Oracle中left join 与 (+) 的区别
避坑,Oracle中left join 与 (+) 的区别
|
SQL Oracle 关系型数据库
解决:Oracle数据库中Left join on 后面为null时匹配不上
解决:Oracle数据库中Left join on 后面为null时匹配不上
305 0
|
6月前
|
消息中间件 存储 Kafka
实时计算 Flink版产品使用问题之 从Kafka读取数据,并与两个仅在任务启动时读取一次的维度表进行内连接(inner join)时,如果没有匹配到的数据会被直接丢弃还是会被存储在内存中
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
4月前
|
SQL 分布式计算 大数据
"大数据计算难题揭秘:MaxCompute中hash join内存超限,究竟该如何破解?"
【8月更文挑战第20天】在大数据处理领域,阿里云的MaxCompute以高效稳定著称,但复杂的hash join操作常导致内存超限。本文通过一个实例解析此问题:数据分析师小王需对两个共计300GB的大表进行join,却遭遇内存不足。经分析发现,单个mapper任务内存默认为2GB,不足以支持大型hash表的构建。为此,提出三种解决方案:1) 提升mapper任务内存;2) 利用map join优化小表连接;3) 实施分而治之策略,将大表分割后逐一处理再合并结果。这些方法有助于提升大数据处理效率及稳定性。
86 0
|
4月前
|
Oracle 关系型数据库
分布式锁设计问题之Oracle RAC保证多个节点写入内存Page的一致性如何解决
分布式锁设计问题之Oracle RAC保证多个节点写入内存Page的一致性如何解决
|
7月前
|
存储 NoSQL Oracle
Oracle 12c的内存列存储:数据的“闪电侠”
【4月更文挑战第19天】Oracle 12c的内存列存储以超高速度革新数据处理,结合列存储与内存技术,实现快速查询与压缩。它支持向量化查询和并行处理,提升效率,但需合理配置以平衡系统资源。作为数据管理员,应善用此功能,适应业务需求和技术发展。
|
7月前
|
计算机视觉
OpenCV报错: cv::Exception,位于内存位置 0x00000078226FEE58 处。
OpenCV报错: cv::Exception,位于内存位置 0x00000078226FEE58 处。
|
7月前
|
SQL Oracle 关系型数据库
Oracle查询优化-left join、right join、inner join、full join和逗号的区别
【1月更文挑战第5天】【1月更文挑战第13篇】实际查询时,多表联查是常规操作,但是连接方式有多种。
563 0
|
SQL Oracle 关系型数据库
java实现oracle和mysql的group by分组功能|同时具备max()/min()/sum()/case when 函数等功能
java实现oracle和mysql的group by分组功能|同时具备max()/min()/sum()/case when 函数等功能
|
Oracle 关系型数据库 数据库
一篇文章带你了解Oracle 数据库中 CROSS JOIN(cross join) 语法的作用
一篇文章带你了解Oracle 数据库中 CROSS JOIN(cross join) 语法的作用
962 0

推荐镜像

更多
下一篇
无影云桌面