本系列文章将为DBA介绍Oracle Database 12c 中的内存数据库选件，第一部分将主要介绍一些基础知识和部署的注意事项。第二部分则会着眼于在采用内存数据库选件情况下潜在的许可和硬件成本等问题。

Oracle Database 12c内存数据库选件(In-Memory Option)将于今年正式发布，它为传统的Oracle数据库引入了内存以及列存储等新特性。Oracle内存数据库选件能够大幅提升分析查询的性能并且还会在一定程度上加速在线事务处理(OLTP)。

目前关于新功能的说明文档还是比较缺乏的，尤其是在新产品许可成本方面以及部署所需硬件资源方面可查的参考资料不多。

传统来讲，Oracle数据库中的数据是以“行”操作格式存储在磁盘上的。但是，Oracle内存数据库选件使得12c可以让数据以列操作的方式存储在内存中。数据库仍然保留了行存储方式用于OLTP，但是会拷贝数据到内存以供只读分析查询的存储之用。这种双重格式为事务数据提供了实时、随机的分析能力。此外，如果OLTP数据库已经支持商业智能(BI)操作，则In-Memory Option将省去分析索引，从而也间接改善了OLTP的性能。

在去年9月OpenWorld的展示中，Ellison表示以数据驱动的应用程序将不需要进行任何修改，而且DBA只需简单地按下开关就可以实现新的内存功能。在数据拷贝到内存后，分析查询会自动定向到分析引擎，它使用列式数据来获得每秒数十亿次的扫描率。由于数据是存储在内存中的，查询不会引起和数据存储在磁盘上一样典型的I/O消耗。同时，对于OLTP查询来说，它们被定向到OLTP引擎并使用磁盘数据。数据库引擎会确保这两种数据存储的事务一致性并同时可用。

内存数据库选件的部署

首先不要被厂商“开箱即用”的宣传所蒙蔽。每当DBA修改一个系统的时候，都可能会引起开发，部署以及质量保证方面的额外工作和开销。在没有进行充分测试的情况下，我们不建议企业将一项新技术直接投入生产环境。

举例来说，假设你计划部署一个基于OLTP数据库的BI系统。往往我们会采取更为传统的方式：建立一个数据仓库，设立ETL操作并部署一个提供持续维护和支持的系统。这样的BI平台不仅需要规划、开发、测试等资源，而且还需要支持软件、数据和网络通信的物理设施。

然而，使用Oracle内存数据库选件就可以完全跳过数据仓库的方法。取而代之的是建立一个单独的架构，即扩大已有的OLTP架构。当然，此平台需要为许可，部署和基础设施支付一个初始费用，但可以在硬件、系统维护等其他方面节省一定成本。即使你需要专门的硬件来运行内存数据库选件，在总体拥有成本上仍然会获益。当然，在我们还没有关于许可成本和硬件要求的更多文档之前，我们也只能是对这点加以揣测。

另一方面，如果你已经部署了一个单独的数据仓库，那么就可能不太适合再对内存数据库选件进行投入，特别是如果你的系统已经平稳运行起来，并且已经做了大量初始投资的情况下。你需要在实施之前评估内存数据库选件的实时优势能否补偿规划，开发和测试系统的成本，当然还有硬件和许可本身的成本。

不论你是否部署了数据仓库，都要考虑其他几个与成本相关的问题。首先，你必须要决定如何处理历史数据。之所以要将一个数据仓库以一个单独系统加以对待，是因为它服务于历史数据，而不是相关的日常事务处理。数据仓库为那些随时间变化需要更广泛角度的分析提供了所需要的更大的范围。如果利用OLTP系统进行分析，你就必须考虑积累的数据并确保拥有处理它的系统和流程。大量的历史数据可能会占满内存并影响性能。并不是所有的BI平台都能用OLTP环境作支持的。

此外，当BI作为一个单独系统存在时，OLTP与数据仓库平台将不会互相影响，反之亦然。也就是说如果其中之一出现问题，而另一个会继续运行。这样如果系统在遇到问题时就会更容易进行故障排除和维护，受影响的用户也会控制到最少。例如，一个处理量大的分析查询不会影响那些同时运行着OLTP操作的所有用户。如果你计划将OLTP和BI系统整合成一个单一系统，那么就必须为应急预案和涉及的潜在成本做好计划。

另外一种要考虑的情况是已经用了OLTP数据库做分析，也就是说很可能应用了分析索引来改善性能。这里需要提醒，它们可能会严重影响你的OLTP操作。如此一来，一旦对许可和系统需求的文档有了良好的理解，那么内存数据库选件便可能是值得投资的。这种方法对于探索性(调查)类型的分析和操作分析可能尤为好用，它们都是有内置分析的操作应用程序的一部分。如果你选定此方法，要记住，除了额外的硬件成本外，任何级别的更新都是需要必要的资源来加以实施并支持这些变更。