文章
数据库
Oracle Database In-Memory (12.1.0.2) Frequently Asked Question
作者：张乐奕
2014 年 12 月发布
Oracle Database In-Memory 选件于美国时间 6 月 10 日已经发布，发布会视频参看：http://www.oracle.com/us/corporate/events/dbim/index.html
什么时候 Oracle Database In-Memory 选件能够发布？
该选件将包含在 Oracle Database 12c 的第一个 Pacthset (12.1.0.2) 中一起发布。
价格如何？
价格会在发布日的时候决定。
新的 Oracle Database In-Memory 选件是否会替代 In-Memory Database Cache（就是 TimesTen 技术）选件？
当然不，完全不一样的应用场景。In-Memory Database Cache 是在应用程序层通过 TimesTen 来管理的内存性质的数据库，这是为了让 OLTP 应用享受到对于存储在 Oracle 数据库中一部分表的超低延迟访问而设计的。
Oracle Database In-Memory 选件是否会替代 TimesTen？
当然不。像上面所说，TimesTen 通常是部署在应用层的，可能是作为一个独立的数据库，也可能是作为在 Oracle 数据库前面的 In-Memory Database Cache。TimesTen 提供的是超低延迟数据访问，由此提供了极速的响应时间。由此受益的 OLTP 系统通常不会创建用于报表应用的索引，也因此通常无法从数据库层的 Oracle Database In-Memory 选件中获得多少性能提升。
Oracle Database In-Memory 选件是否会替代 Exalytics？
当然不。并不是所有客户都需要在他们的系统中拥有强力的分析能力，而 Exalytics 是 Oracle 的一体化策略分析平台。它提供了丰富的分析工具和可视化工具，以及大量的标准报表、预测分析、数据发现，是为了最优化地运行 BI 和 EPM 工作的平台，是对数据库层的补充而不是竞争。 Exalytics 也不仅仅是针对 Oracle Database 12c 的，它可以处理多种数据源，包括 Teradata、Oracle database 11g、SAP Netweaver 等。
那么在 Exalytics 中使用的是什么关系型内存数据库引擎呢？
Exalytics 使用的是 TimesTen In-Memory Database for Exalytics。在 TimesTen 产品发展路线图中也包含着跟 Oracle Database In-Memory 选件相类似的列式存储技术，而且是使用的相同的底层列式处理架构。这项技术计划在 2014 年跟 Oracle Database In-Memory 选件一起在相同的时间窗口发布。实际上，TimesTen 和 Oracle Database In-Memory 选件在 Oracle 公司内部是由同一个小组来开发的，共享相同的创新技术以及底层架构。
那么在 Exalytics 中使用的内存数据库引擎在未来会变成 Oracle Database In-Memory 选件吗？
没有这个计划。Oracle 期望 TimesTen 会持续研发。
Oracle Database In-Memory 选件是否会替代 Exadata？
当然不。这个问题太幼稚，就不做解释了。
好吧，那到底什么是 Oracle Database In-Memory 选件呢？
这是一项新的技术，内置在 Oracle 数据库中，通过内存中的列式存储数据来获得超快的数据处理能力。
当使用 Oracle Database In-Memory 时，数据库的大小受限于服务器中的可用内存容量吗？
不。由用户来决定哪些对象会存在 In-Memory 列式缓存中。如果一张表太大了，无法完全缓存在 In-Memory 列存中，Oracle 会尝试将尽可能多的数据保持在内存中（以列的形式），剩下的仍然存储在闪存或者磁盘中（以原来行的形式），这样的操作非常高效并且是完全透明的。 你可以有选择性的定义一部分数据库，比如将热表、热分区、经常访问的列放入内存中。这就让除了 Oracle 原有的那些跨越内存、闪存、磁盘的各种优化方式之外，Oracle Database In-Memory 选件还能够专门为频繁访问的业务关键数据提供帮助。当然，如果数据库足够小，全部表都能使用 Oracle Database In-Memory 选件。
Oracle Database In-Memory 选件只会对分析/报表类业务有帮助吗？
虽然确实分析/报表类业务能够从列式存储中获得最多的收益，但是其他类型业务也同样能够受益。比如通过减少需要的索引，就能够加速 OLTP 业务。通常在以前的混合负载业务中需要在表上创建很多的多字段索引来支撑报表类型的查询，如今 In-Memory 列存则对 DML 操作造成更少的影响，而又可以提供相同的查询性能。 减少索引还能够带来优化和管理的简便，DBA 不再需要去 rebuild 那些碎片化的索引，也不再需要去研究为什么优化器选择了错误的索引。
从 Oracle Database In-Memory 功能中能够期望获得多少性能提升？
使用该选项能够为多种查询负载提供显著的性能提升。从一个非常简单的星型查询到一个非常复杂的具有多个子查询的 SQL，就算所有的的表都在内存中，In-Memory 列式缓存仍然会胜过普通的 Buffer Cache。 比如说，In-Memory 列存在查询很少列上的很多行时，会提供极高的性能，通常这类查询都是分析类的查询，在这类查询上使用 In-Memory 列存和使用普通缓存 (Buffer Cache) 相比，有超过 100 倍的性能提升。
当使用 Oracle Database In-Memory 选件的时候，我该对索引做些什么吗？
你可以保留以前的所有索引，就像以前那样运行你的应用。Oracle 优化器完全能够感知到内存中的列式数据，只有当确认使用这些列式数据会有性能提升的时候才会使用到，如果优化器认为从索引访问中能够获得更好的性能，那么就会自动去读取普通缓存 (Buffer Cache) 中的数据，就跟以前一样。 不过，如果将一些多列索引设置为 invisible，引导 Oracle 优化器更多地去选择列式缓存，可能会带来额外的速度提升。然后，你可以删除掉这些无用的索引，这样又能带来进一步的性能提升，因为 Oracle 数据库需要维护的索引更少了。
如果使用 Oracle Database In-Memory 选项，数据库现在的功能会受影响吗？
没有任何一项现有的 Oracle 数据库功能会受到 Oracle Database In-Memory 选项的限制；很多操作还能在性能上获得显著提升；一些原本为了提高性能所做的操作（比如创建索引）会变得不再重要；安全性、高可用性以及其它的所有功能都跟以前一模一样，完全不受影响。 当然在 DML 操作上会有一些额外消耗，因为 In-Memory 列存要时刻跟表数据保持同步，但是这部分列存是完全在内存中的，所以不需要额外的 Logging 操作。
Oracle Database In-Memory 选项在高可用性上跟其它厂商的内存数据库相比如何？
因为 In-Memory 列存并没有给 Oracle 数据库施加任何限制，因此在高可用性上可以享受 Oracle 数据库完整的丰富的高可用解决方案，而其它厂商的高可用性均不太完备。
如何规划 In-Memory 列存所需要的内存大小？
In-Memory Area（用于保存 In-Memory 列存的内存区域）是 SGA 中的一块新的缓存池，该缓存大小由初始化参数 INMEMORY_SIZE 指定，如果一旦设定，最小是 100MB。因为 In-Memory Area 是 SGA 的一部分，因此其最大大小受制于分配了其它所有内存池之后的 SGA 中的剩余空间。INMEMORY_SIZE 默认是 0，也就是不启用 Oracle Database In-Memory 选项。 由于 In-Memory Area 是一块静态区域，所以不会被自动内存管理算法所影响。 如果想要修改 In-Memory Area 的大小，需要重启数据库实例，在 RAC 数据库中，可以在各实例的内存中复制 In-Memory 列存，因此可以通过重启节点的方式来最小化对应用的影响。
在 RAC 环境中，是否 In-Memory 列存是在集群的所有节点中完全镜像的？
在 RAC 环境中，用户可以自行设定使用以下三种选项中的任何一种： 1. 在所有实例的内存中镜像相同的表数据。这样每个实例都会读取自己的本地内存，通常这用于较小的表。 2. 表数据分布在所有实例的内存中。这样每个实例内存中只会保存表中的一部分数据，没有冗余复制。 3. 表数据分布在所有实例的内存中，并且为高可用性保留2份镜像。这种工作机制很像 ASM 的条带化和冗余性。
鼓励发表数据库选件 (DBO) 相关的内容或在 Oracle 技术网上发表文章。参见在 Oracle 技术网上发表技术文章。
Printer View