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的条带化和冗余性。
