OLTP、OLAP、VDI和SPC-1是目前性能评估中常见的三种业务场景。SPC-1是业界常用的随机IOPS型IO模型。该模型常用于实际服务类型未知时的性能评估。四种型号的简单IO特性如下表所示。Oracle数据库是典型的OLTP业务模型，广泛应用于核心IT业务系统。OLTP类型的Oracle数据库往往承载着企业的核心业务支撑系统，如ERP、CRM等，在性能和可用性方面存在问题。本章重点分析OLTP和OLAP的主要区别，基于Oracle的规划方法和最佳实践。OLTP和OLAP简介数据处理大致可以分为两类：OLTP（On-lineTransactionProcessing）和OLAP（On-LineAnalyticalProcessing）。OLTP是传统关系型数据库的主要应用，主要用于基础的、日常的事务处理，比如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重于决策支持，提供直观易懂的查询结果。OLTP与OLAP的比较：OLTP应用的IO特性OLTP通常指的是一个事务性非常高的在线系统，主要是小事务和小查询。在评估其系统时，一般取决于每秒执行的Transaction和ExecuteSQL的数量。在这样的系统中，单个数据库往往每秒处理数百或数千个Transaction，而Select语句的执行量是每秒数千甚至数万。典型的OLTP系统包括电子商务系统、银行、证券等：每次I/O很小，一般为2KB~8KB访问磁盘数据的位置非常随机至少30%的数据是随机写操作在线重做日志写入非常频繁的顺序写入1.业务特点：每次事务的读、写、改涉及的数据量很小，很多用户同时连接数据库，使用数据库需要数据库有一个快速的响应时间。通常，一笔交易在几秒内完成，延迟要求一般在10-20ms。2、IO特性：对于DATALUN，随机小IO，IO大小以8KB为主（IO大小与数据库的block大小一致），读写比约为3:2，读取全随机,而写在一定程度上被合并了。对于LOGLUN，多通道顺序小IO，大小可变，几乎都是写IO。OLTP系统的瓶颈除了服务器的CPU，还有存储系统的IOPS处理能力。因为在OLTP环境下，硬盘的物理读一般都是dbfilesequentialread，即单个数据块的物理读，但是读的次数非常频繁。如果频繁到硬盘子系统无法承受其IOPS，就会出现很大的性能问题。OLAP应用的IO特性OLAP系统，又称DSS决策支持系统，就是我们所说的数据仓库。在这样的系统中，报表作业大部分时间都在数据库上运行，执行基本聚合的SQL操作，比如Groupby，同时扫描很多行，一次查询需要数小时甚至数天，量一次读取的数据量很大；一般没有数据修改，或者只有很少的数据修改：单次I/O非常大，典型值为64KB~1MB读操作是顺序读当读操作在进行时，发生的写操作是通常很少写入临时表空间的在线日志，批量加载数据时除外1.业务特点：一般数据修改很少，批量加载数据时除外；系统调用非常复杂的查询语句，同时扫描很多行；查询将花费数小时甚至数天；主要取决于查询语句的复杂程度；查询的输出通常是通过groupby和orderby得到的一个统计值；当读操作正在进行时，发生的写操作通常在临时表空间；通常很少写入在线日志，除非是批量加载数据；分析服务一般不需要延迟。2、IO特性：对于DATALUN，多通道顺序大IO（可以认为是随机大IO），IO的大小和host端设置的stripesize有关（比如512KB），90%以上的读取业务，混合间歇读取写入。对于TMPLUN，随机IO，混合读写（先写后读，计算时写，读临时表时读，大部分是写，占整个业务IO的一小部分），IO大小基本上是200KB以上的大IO。OLTP系统最容易出现的瓶颈是存储系统的带宽。阵列的带宽往往取决于从主机到阵列的前端网络和后端硬盘的数量。这时候数组缓存基本没有作用，数据库的读写类型基本都是dbfilescatteredread和directpathread/write。在实际应用中，既然OLTP存储了大量的详细数据，为什么不直接在OLTP上进行分析处理呢？由于OLTP主要设计用于操作数据（操作系统），它用于处理已知的任务和负载：常见的优化在于主键索引和散列，检索特定记录。优化一些特定的查询语句。另一方面，OLAP是为数据分析（数据仓库）而设计的。其查询方式往往复杂且未知，通常涉及大量数据汇总后的计算。这种基于多维视图的数据操作是在OLTP上进行的。有时性能会很差，也极度危险。但是OLAP系统的数据源不同于各种OLTP数据库。由于OLTP系统中存储的数据往往是异构的，OLAP系统需要通过转换（ETL）对来自OLTP的各种异构数据进行转换和合并。在设计中要特别注意分离设计和优化。比如在高可用的OLTP环境下，不要盲目使用OLAP技术。比如分区技术，假设partitionkey没有被广泛使用，而是使用其他字段作为where条件，那么，如果是本地索引，就要扫描多个索引，性能会变得更低。如果是全局索引，就失去了分区的意义。并行技术也是如此，一般在完成大型任务时使用。比如在现实生活中，翻译一本书时，可以先安排多人，每个人翻译不同的章节，这样可以提高翻译速度。如果你只翻译一页书，没必要指派不同的人翻译不同的行然后组合起来，因为一个人可能已经在分配的工作时间内翻译完了。位图索引也是如此。如果在OLTP环境下使用，很容易造成阻塞和死锁。但是在OLAP环境下，由于其独特的特性，可能会提高OLAP的查询速度。MV基本相同，包括触发器等。在DML频繁的OLTP系统中，很容易成为瓶颈，甚至LibraryCache等待，而在OLAP环境中，如果使用得当，可能会提高查询速度。数据库模板Oracle10g之前版本建库过程中可用的模板包括：DataWarehouse（数据仓库）、GeneralPurpose（通用、通用）、NewDatabase、TransactionProcessing（事务处理）Oracle11g版本数据库构建过程中可以选择的模板包括：通用或事务处理、自定义数据库、数据仓库等；我个人对这些模板的理解是：联机分析处理（OLAP），数据量大，DML少。使用数据仓库模板；联机事务处理（OLTP），数据量少，DML频繁，并行事务处理多，但一般都很短。使用通用或交易模板。决策支持系统（DDS，Decisionsupportsystem），典型的操作是全表扫描、长查询、长事务，但一般事务的数量很少，往往是事务独占系统。最佳实践Oracle数据库广泛应用于核心IT业务系统，存储子系统的规划和配置至关重要。不合理的存储规划往往导致IT系统性能不佳，甚至无法保证可用性和数据可靠性。OLTP型Oracle数据库往往承载着企业的核心业务支撑系统，如ERP、CRM等，其性能和可用性问题将直接导致企业运营效率低下甚至中断。本文OLTP业务测试模型采用SwingBenchOrderEntry进行验证。该业务模型定义了一个在线订单业务，模拟大量用户登录系统进行交易系统最常见的操作，如产品查询、订单发送、订单处理、订单查看等。该业务模型有两个主要性能指标：每分钟事务数（TPM）和事务平均响应时间。TPM代表系统在单位时间内可以处理的交易量，TPM高代表生产力越强。交易响应时间直接影响用户操作完成的速度，交易响应时间越短代表用户体验越好。OrderEntry业务模型一共定义了9张表来记录产品、客户、订单、仓库、登录等信息。进行负载测试时，50%是查询操作，30%是插入操作，20%是更新操作，没有删除操作。从I/O层来看，业务模型是随机访问小数据块，读写比为6:4，是最典型的OLTP业务模型之一。SAN（StorageAreaNetwork）组网中，使用两个物理上独立的交换平面（每个交换平面包括一个交换机或多个相互级联的交换机），每个数据库节点连接两个交换平面，每个存储控制器连接两个交换平面飞机。OracleRAC组网示意图对于Oracle数据库来说，I/O队列深度是影响性能的一个重要参数。操作系统层有两个参数影响I/O队列深度：块设备队列深度和HBA卡队列深度。建议按照以下策略配置块设备队列深度和HBA卡队列深度。对于Linux操作系统，块设备最大队列深度为128，HBA卡的队列参数与卡类型和驱动有关。请参考HBA厂商给出的规格值，如Qlogic8GbpsFC双口HBA卡，限制了每个LUN最大队列深度为32，建议通过增加LUN的数量。对于AIX操作系统，华为建议安装UltraPath多路径，不要安装系统多路径或第三方多路径。安装华为UltraPath多路径后，最大块设备队列深度调整为32，如果不使用华为UltraPath，系统默认块设备最大队列深度为5，建议将该值修改为32或更高。AIXHBA卡最大队列深度默认值为200，可根据实际业务需要进行调整。对于Windows操作系统，单个LUN的最大I/O队列深度还取决于HBA卡厂商给出的规格值。Oracle11g数据库OLTP业务下，建议调整如下参数。参数的最优值应根据实际业务进行测试和调整，以获得最佳的性能和可靠性。下表列出了关键参数的含义和推荐值：使用SwingBench测试和配置特定用户会话数，测试性能如下：最佳实践介绍部署基于Oracle数据库的规划和配置方案在存储系统上，并提供经过验证的Plan配置参考架构。用户在为存储阵列规划和部署Oracle11g时，可以利用提供的组网、参数设置、测试方法等信息在实践中提供指导，降低方案规划的负担和实施过程中的风险。
