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 业务下，建议针对以下参数进行调整，参数的最佳值应根据实际业务进行测试调整，以获取最佳性能和可靠性。下表列出了关键参数的含义和推荐值：

采用 SwingBench 测试，配置特定用户会话数，测试出来的性能如下：

最佳实践介绍了基于存储系统部署 Oracle 数据库的规划配置方案，并提供经验证的规划配置参考架构。用户在 存储阵列规划、部署 Oracle 11g 时可以利用提供的组网、参数设置、测试方法等等信息，在实践中予以指导，减少方案规划时的负担与实施过程中的风险。