很多人都在谈论为什么或者为什么不在他们的应用程序中使用 Oracle In-memory 数据库，他们中的大多数都过于关注数据库的大小，或者它是否是 OLAP 应用程序。中小型数据库似乎不适合使用 Oracle In-memory数据库选项。但是，如果您的 OLTP 数据库存在性能瓶颈，并且您正在寻找解决方案，我认为 Oracle In-memory数据库选项应该位于您的解决方案列表中，尤其是在计划升级硬件时。
在Oracle In-Memory 数据库中，SQL优化器优化计划空间越来愈大
计划空间是数据库 SQL optimizer 在输入 SQL 语句之前将考虑的潜在处理方法的大小。更大的计划空间大小意味着数据库 SQL optimizer 将考虑处理 SQL 语句的更多潜在方法。因此，您的 SQL 语句有更多运行更快的机会。使用 Oracle In-Memory 数据库新的 In-Memory数据访问方法，Oracle SQL 优化器将在 SQL 语句执行之前考虑更大的计划空间。由于乘数效应，新的 In-Memory 执行计划步骤可能会导致计划空间大小发生巨大扩展。例如， In-Memory 包含 5 个表的 SQL 语句，每个表的访问方法的”Table Access Inmemory Full”步骤，结果是 C（5，1）+C（5，2）+C（5，3）+C（5，4）C（5，5）=5=10=10=5=1=31。但不要忘记，此乘法器适用于原始计划空间树中的每个执行计划，这意味着新计划空间大小可能比原始计划空间大 31 倍。
OLTP 数据库如何从 In-Memory 数据库中获得优势?
OLTP 数据库是面向事务的应用程序，它要求每个事务都有快速的响应时间，但这并不意味着在工作时间没有用于联机报告或数据整合的复杂 SQL。如果此类慢速的 SQL 语句与其他联机事务同时运行，则整体性能将受到影响。如果硬件升级是其中一个选项，应考虑使用 Oracle In-Memory作为替代解决方案之一。
下面的示例向您展示了OLTP SQL语句如何从使用Oracle In-Memory数据库选项中获益。
下面是一个典型的 OLTP SQL，对所有表都进行了分析，原始执行计划显示了一个 Oracle 自适应计划，其中哈希联接或嵌套循环将在执行的初始阶段确定。此 SQL 的运行时间约为 1 分 35 秒。
L让我们使用强制提示将 EMPLOYEE 表放入Oracle In-Memory中，然后 Oracle 访问它时，采用”Table Access Inmemory Full”扫描，下面的基准测试显示，“Auto 1” SQL仅花费0.45秒就完成了，比原始执行计划快200多倍。该解决方案表明，对EMPLOYEE表引入新的“Table Access Inmemory Full”扫描，创建了比原来更好的执行计划。
对于OLTP的SQL，不需要将所有表放入 In-Memory
使用 OLTP 数据库时，我们不希望将所有表填充到In-Memory，从而给联机事务带来过多的开销。因此，对于OLTP 的 SQL 使用 In-Memory SQL 调优的目标不是选择最佳性能解决方案，而是具有较少In-Memory表的最经济高效的解决方案，且其性能改进仍是可以接受的。
如下面： “Auto 3” 解决方案把包含的所有表都被放入In-Memory，但改进仅比 “Auto 1” 高 0.01 秒，后者只需要将一个表放入In-Memory。因此，”Auto 1″显然是一个更可取的选择。
Oracle应该根据 In-Memory 的大小为 In-Memory 选项装载
实际上，Oracle In-Memory数据库不仅仅有利于OLAP用户，而是对于所有数据库用户(比如OLTP用户)来说，都是一个很好的SQL性能增强工具。鉴于Oracle In-Memory 数据库选项定价过高，限制了该新技术的快速适应，建议Oracle根据 In-Memory 大小来决定价格。换句话说，更小的尺寸和更低的价格肯定会帮助 Oracle
In-Memory数据库可广泛渗透到所有数据库用户，包括 OLTP 用户。
Author: Richard To (Richard.to@tosska.com), CTO of Tosska Technologies Limited