OLTP与OLAP概念、主要区别和完美实践

OLTP、OLAP、VDI和SPC-1是当前性能评估中常见的三类业务场景。SPC-1是业界通用的随机IOPS型的IO模型，在不清楚实际业务类型的条件下，常用此模型来进行性能评估。四种模型的简单IO特征如下表所示。

Oracle 数据库是典型的的OLTP业务模型，在核心 IT 业务系统中应用广泛，OLTP类型的 Oracle 数据库往往承载着企业核心的业务支撑系统，如 ERP、CRM 等，其性能和可用性出现问题，本章重点剖析OLTP和OLAP主要区别、规划方法及基于Oracle的最佳实践。

OLTP与OLAP的介绍

数据处理大致可以分成两大类：联机事务处理OLTP(On-line transaction processing)、联机分析处理OLAP(On-Line Analytical Processing)。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。

OLTP与OLAP之间的比较：

OLTP应用的IO特征

OLTP通常是指事务性非常高的在线系统，以小的事务以及小的查询为主，评估其系统的时候，一般看其每秒执行的Transaction以及Execute SQL的数量。在这样的系统中，单个数据库每秒处理的Transaction往往超过几百个，或者是几千个，Select语句的执行量每秒几千甚至几万个。典型的OLTP系统有电子商务系统、银行、证券等：

每个I/O非常小，通常为2KB~8KB
访问磁盘数据的位置非常随机
至少30%的数据是随机写操作
联机重做日志是写入非常频繁的顺序写

1、业务特征：每个事务的读，写，更改涉及的数据量非常小，同时有很多用户连接到数据库，使用数据库，要求数据库有很快的响应时间，通常一个事务在几秒内完成，时延要求一般在10-20ms。

2、IO特征：针对DATA LUN，随机小IO，IO大小主要为8KB(IO大小与数据库的Block块大小一致)，读写比约为3:2，读全随机，写有一定合并。针对LOG LUN，多路顺序小IO，大小不定，几乎都是写IO。

OLTP系统最容易出现瓶颈的地方除了服务器的CPU，就是存储系统IOPS处理能力。因为在OLTP环境中，硬盘物理读一般都是db file sequential read，即单个数据块物理读，但是这个读的次数非常频繁。如果频繁到硬盘子系统都不能承载其IOPS的时候，就会出现大的性能问题。

OLAP应用的IO特征

OLAP系统，也称为DSS决策支持系统，就是我们说的数据仓库。在这样的系统中，绝大多数时候数据库上运行着的是报表作业，执行基本上是聚合类的SQL 操作，比如Group by，同时扫描非常多的行，一个查询将花费数小时，甚至数天，一次读取的数据量大;一般无数据修改，或者只有非常少的数据修改：

单个I/O很大，典型的值为64KB~1MB
读取操作为顺序读取
当读取操作进行时，发生的写操作通常在临时表空间内
平常对在线日志写入很少，除非在批量加载数据时

1、业务特征：一般很少有数据修改，除非在批量加载数据时;系统调用非常复杂的查询语句，同时扫描非常多的行;一个查询将花费数小时，甚至数天;主要取决于查询语句的复杂程度;查询的输出通常是一个统计值，由group by与order by得出;当读取操作进行时，发生的写操作通常在临时表空间内;平常对在线日志写入很少，除非在批量加载数据时;分析型业务，一般对时延没有要求。

2、IO特征：针对DATA LUN，多路顺序大IO(可以近似认为是随机大IO)，IO大小与主机侧设置的分条大小有关(如512KB)，90%以上为读业务，混合间断读写。针对TMP LUN，随机IO，读写混合(先写后读，计算时写，读临时表时读，大部分是写，占整个业务中很少部分的IO)，IO大小基本为200KB以上大IO。

OLTP系统最容易出现瓶颈的地方是存储系统的带宽。阵列的带宽则往往取决于主机到阵列的前端网络和后端硬盘的个数，这个时候，阵列CACHE基本是没有效果的，数据库的读写类型基本上是db file scattered read与direct path read/write。

在实际应用中，既然OLTP中存放了大量的细节数据，为什么不直接在OLTP上进行分析处理呢?

由于OLTP主要是为了操作数据而设计(操作系统)，用于处理已知的任务和负载：常见的优化在于主码索引和散列，检索特定的记录。去优化某一些特定的查询语句。

而OLAP则是为了分析数据而设计(数据仓库)，其查询的方式往往是复杂且未知的，通常会涉及大量数据在汇总后的计算，这种需要基于多维视图的数据操作在OLTP上执行的时候性能将是非常差的，并且是也是极其危险的。

但是OLAP系统数据来源与各种OLTP数据库。因为OLTP系统存储的数据往往是异质的，所以OLAP系统需要把各种来源于OLTP的异质数据通过转换(ETL)做到同质并且合并。

分开设计与优化

在设计上要特别注意，如在高可用的OLTP环境中，不要盲目地把OLAP的技术拿过来用。

如分区技术，假设不是大范围地使用分区关键字，而采用其它的字段作为where条件，那么，如果是本地索引，将不得不扫描多个索引，而性能变得更为低下。如果是全局索引，又失去分区的意义。

并行技术也是如此，一般在完成大型任务时才使用，如在实际生活中，翻译一本书，可以先安排多个人，每个人翻译不同的章节，这样可以提高翻译速度。如果只是翻译一页书，也去分配不同的人翻译不同的行，再组合起来，就没必要了，因为在分配工作的时间里，一个人或许早就翻译完了。

位图索引也是一样，如果用在OLTP环境中，很容易造成阻塞与死锁。但是，在OLAP环境中，可能会因为其特有的特性，提高OLAP的查询速度。MV也是基本一样，包括触发器等，在DML频繁的OLTP系统上，很容易成为瓶颈，甚至是Library Cache等待，而在OLAP环境上，则可能会因为使用恰当而提高查询速度。

数据库模板

Oracle 10g以前的版本建库过程中可供选择的模板有：Data Warehouse (数据仓库)、General Purpose (通用目的、一般用途)、New Database和Transaction Processing (事务处理)

Oracle 11g的版本建库过程中可供选择的模板有：一般用途或事务处理、定制数据库、数据仓库等;个人对这些模板的理解为：

联机分析处理(OLAP)，数据量大，DML少。使用数据仓库模板;

联机事务处理(OLTP)，数据量少，DML频繁，并行事务处理多，但是一般都很短。使用一般用途或事务处理模板。

决策支持系统(DDS，Decision support system)，典型的操作是全表扫描，长查询，长事务，但是一般事务的个数很少，往往是一个事务独占系统。

最佳实践

Oracle 数据库在核心 IT 业务系统中应用广泛，存储子系统的规划配置至关重要，不合理的存储规划往往导致 IT 系统性能低下，甚至可用性和数据可靠性得不到保证。OLTP类型的 Oracle 数据库往往承载着企业核心的业务支撑系统，如 ERP、CRM 等，其性能和可用性出现问题，会直接导致企业运营效率低下甚至中断。

本文OLTP 业务测试模型采用 SwingBench Order Entry 进行验证。该业务模型中定义了一种在线订单业务，模拟大量用户登陆系统，执行产品查询、下发订单、处理订单、查看订单等交易系统最常见的操作。该业务模型的主要性能指标有两个：每分钟事务数(TPM)、事务平均响应时间。TPM 代表系统在单位时间内所能够处理的交易量，TPM 高，代表着更强的生产力。事务响应时间直接影响到用户操作完成的速度，事务响应时间低，代表着更佳的用户体验。

Order Entry 业务模型中共定义了 9 张表，记录产品、客户、订单、仓库、登陆等信息。在执行负载测试时，50%为查询操作，30%为插入操作，20%为更新操作，无删除操作。从 I/O 层来看，该业务模型为小数据块随机访问，读写比例为 6:4，代表一种最为典型的 OLTP 业务模型。

在SAN(Storage Area Network)组网中，使用两个物理上独立的交换平面(每个交换平面包括一个交换机或多个相互级联的交换机)，每个数据库节点与两个交换平面相连，每个存储控制器和两个交换平面相连。

Oracle RAC 组网示意图

对于 Oracle 数据库来说，I/O 队列深度是影响性能的重要参数。操作系统层存在两个参数影响到 I/O 队列深度：块设备队列深度和 HBA 卡队列深度。建议按照如下策略配置块设备队列深度和 HBA 卡队列深度。

对于 Linux 操作系统，块设备最大队列深度为 128，而 HBA卡的队列参数与卡类型和驱动程序相关，请参考 HBA 厂商给出的规格值，如 Qlogic 8Gbps FC 双口 HBA 卡，限制每个 LUN 的最大队列深度为 32。而建议采用增加 LUN 个数的方式提高整体 I/O 队列深度。

对于 AIX 操作系统，华为建议安装 UltraPath 多路径，而不建议使用系统多路径或第三方多路径。安装了华为 UltraPath 多路径，块设备最大队列深度被调整为 32，若不使用华为 UltraPath，系统默认块设备最大队列深度为 5，建议将此值修改为 32 或更高。AIX 的 HBA 卡最大队列深度默认值为 200，可根据实际业务需求进行调整。

对于 Windows 操作系统，单个 LUN 的最大 I/O 队列深度同样取决于 HBA 卡厂商给出的规格值。

Oracle 11g 数据库 OLTP 业务下，建议针对以下参数进行调整，参数的最佳值应根据实际业务进行测试调整，以获取最佳性能和可靠性。下表列出了关键参数的含义和推荐值：