OLAP、OLTP的介绍CBO/RBO

OLTP与OLAP的介绍

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

OLTP 系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作；
OLAP 系统则强调数据分析，强调SQL执行市场，强调磁盘I/O，强调分区等。

OLTP与OLAP之间的比较：

OLTP，也叫联机事务处理（Online Transaction Processing），表示事务性非常高的系统，一般都是高可用的在线系统，以小的事务以及小的查询为主，评估其系统的时候，一般看其每秒执行的Transaction以及Execute SQL的数量。在这样的系统中，单个数据库每秒处理的Transaction往往超过几百个，或者是几千个，Select 语句的执行量每秒几千甚至几万个。典型的OLTP系统有电子商务系统、银行、证券等，如美国eBay的业务数据库，就是很典型的OLTP数据库。
OLTP系统最容易出现瓶颈的地方就是CPU与磁盘子系统。
（1）CPU出现瓶颈常表现在逻辑读总量与计算性函数或者是过程上，逻辑读总量等于单个语句的逻辑读乘以执行次数，如果单个语句执行速度虽然很快，但是执行次数非常多，那么，也可能会导致很大的逻辑读总量。设计的方法与优化的方法就是减少单个语句的逻辑读，或者是减少它们的执行次数。另外，一些计算型的函数，如自定义函数、decode等的频繁使用，也会消耗大量的CPU时间，造成系统的负载升高，正确的设计方法或者是优化方法，需要尽量避免计算过程，如保存计算结果到统计表就是一个好的方法。
（2）磁盘子系统在OLTP环境中，它的承载能力一般取决于它的IOPS处理能力. 因为在OLTP环境中，磁盘物理读一般都是db file sequential read，也就是单块读，但是这个读的次数非常频繁。如果频繁到磁盘子系统都不能承载其IOPS的时候，就会出现大的性能问题。
    OLTP比较常用的设计与优化方式为Cache技术与B-tree索引技术，Cache决定了很多语句不需要从磁盘子系统获得数据，所以，Web cache与Oracle data buffer对OLTP系统是很重要的。另外，在索引使用方面，语句越简单越好，这样执行计划也稳定，而且一定要使用绑定变量，减少语句解析，尽量减少表关联，尽量减少分布式事务，基本不使用分区技术、MV技术、并行技术及位图索引。因为并发量很高，批量更新时要分批快速提交，以避免阻塞的发生。 
OLTP 系统是一个数据块变化非常频繁，SQL 语句提交非常频繁的系统。 对于数据块来说，应尽可能让数据块保存在内存当中，对于SQL来说，尽可能使用变量绑定技术来达到SQL重用，减少物理I/O 和重复的SQL 解析，从而极大的改善数据库的性能。
    这里影响性能除了绑定变量，还有可能是热快（hot block）。 当一个块被多个用户同时读取时，Oracle 为了维护数据的一致性，需要使用Latch来串行化用户的操作。当一个用户获得了latch后，其他用户就只能等待，获取这个数据块的用户越多，等待就越明显。 这就是热快的问题。 这种热快可能是数据块，也可能是回滚端块。 对于数据块来讲，通常是数据库的数据分布不均匀导致，如果是索引的数据块，可以考虑创建反向索引来达到重新分布数据的目的，对于回滚段数据块，可以适当多增加几个回滚段来避免这种争用。 
    OLAP，也叫联机分析处理（Online Analytical Processing）系统，有的时候也叫DSS决策支持系统，就是我们说的数据仓库。在这样的系统中，语句的执行量不是考核标准，因为一条语句的执行时间可能会非常长，读取的数据也非常多。所以，在这样的系统中，考核的标准往往是磁盘子系统的吞吐量（带宽），如能达到多少MB/s的流量。
    磁盘子系统的吞吐量则往往取决于磁盘的个数，这个时候，Cache基本是没有效果的，数据库的读写类型基本上是db file scattered read与direct path read/write。应尽量采用个数比较多的磁盘以及比较大的带宽，如4Gb的光纤接口。
在OLAP系统中，常使用分区技术、并行技术。
    分区技术在OLAP系统中的重要性主要体现在数据库管理上，比如数据库加载，可以通过分区交换的方式实现，备份可以通过备份分区表空间实现，删除数据可以通过分区进行删除，至于分区在性能上的影响，它可以使得一些大表的扫描变得很快（只扫描单个分区）。另外，如果分区结合并行的话，也可以使得整个表的扫描会变得很快。总之，分区主要的功能是管理上的方便性，它并不能绝对保证查询性能的提高，有时候分区会带来性能上的提高，有时候会降低。
    并行技术除了与分区技术结合外，在Oracle 10g中，与RAC结合实现多节点的同时扫描，效果也非常不错，可把一个任务，如select的全表扫描，平均地分派到多个RAC的节点上去。
    在OLAP系统中，不需要使用绑定（BIND）变量，因为整个系统的执行量很小，分析时间对于执行时间来说，可以忽略，而且可避免出现错误的执行计划。但是OLAP中可以大量使用位图索引，物化视图，对于大的事务，尽量寻求速度上的优化，没有必要像OLTP要求快速提交，甚至要刻意减慢执行的速度。
    绑定变量真正的用途是在OLTP系统中，这个系统通常有这样的特点，用户并发数很大，用户的请求十分密集，并且这些请求的SQL 大多数是可以重复使用的。
    对于OLAP系统来说，绝大多数时候数据库上运行着的是报表作业，执行基本上是聚合类的SQL 操作，比如group by，这时候，把优化器模式设置为all_rows是恰当的。 而对于一些分页操作比较多的网站类数据库，设置为first_rows会更好一些。 但有时候对于OLAP 系统，我们又有分页的情况下，我们可以考虑在每条SQL 中用hint。 如：
    Select  a.* from table a;
分开设计与优化
    在设计上要特别注意，如在高可用的OLTP环境中，不要盲目地把OLAP的技术拿过来用。
    如分区技术，假设不是大范围地使用分区关键字，而采用其它的字段作为where条件，那么，如果是本地索引，将不得不扫描多个索引，而性能变得更为低下。如果是全局索引，又失去分区的意义。
    并行技术也是如此，一般在完成大型任务时才使用，如在实际生活中，翻译一本书，可以先安排多个人，每个人翻译不同的章节，这样可以提高翻译速度。如果只是翻译一页书，也去分配不同的人翻译不同的行，再组合起来，就没必要了，因为在分配工作的时间里，一个人或许早就翻译完了。
    位图索引也是一样，如果用在OLTP环境中，很容易造成阻塞与死锁。但是，在OLAP环境中，可能会因为其特有的特性，提高OLAP的查询速度。MV也是基本一样，包括触发器等，在DML频繁的OLTP系统上，很容易成为瓶颈，甚至是Library Cache等待，而在OLAP环境上，则可能会因为使用恰当而提高查询速度。
    对于OLAP系统，在内存上可优化的余地很小，增加CPU 处理速度和磁盘I/O 速度是最直接的提高数据库性能的方法，当然这也意味着系统成本的增加。      
    比如我们要对几亿条或者几十亿条数据进行聚合处理，这种海量的数据，全部放在内存中操作是很难的，同时也没有必要，因为这些数据快很少重用，缓存起来也没有实际意义，而且还会造成物理I/O相当大。 所以这种系统的瓶颈往往是磁盘I/O上面的。
    对于OLAP系统，SQL 的优化非常重要，因为它的数据量很大，做全表扫描和索引对性能上来说差异是非常大的。
其他
    Oracle 10g以前的版本建库过程中可供选择的模板有：
        Data Warehouse （数据仓库）
        General Purpose  （通用目的、一般用途）
        New Database
        Transaction Processing  （事务处理）
    Oracle 11g的版本建库过程中可供选择的模板有：
        一般用途或事务处理
        定制数据库

数据仓库

个人对这些模板的理解为：

联机分析处理（OLAP,On-line Analytical Processing），数据量大，DML少。使用数据仓库模板
     联机事务处理（OLTP,On-line Transaction Processing），数据量少，DML频繁，并行事务处理多，但是一般都很短。使用一般用途或事务处理模板。

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

=========================================================

CBO介绍：
基于成本的优化器（Cost-Based Optimization）
★计算各种可能的“执行计划”的Cost，从中选择Cost最低的执行方案，作为实际运行方案。
CBO限制：当检索的表达到一定数量之后，就不会有以上特点。

RBO介绍：
基于规则的优化器（Rule-Based Optimization）
★只认规则，对数据不敏感，在Oracle 10g中已被完全取代。

SQL语句优化有以下几个要点：

1.减少对表的检索
2.使用索引
3.减少解析

常用工具：

1.Explain Plan
2.SQL Trace
3.tkprof

1.减少对表的检索

子查询
去除不必要的条件和数据源
EXISTS 和 IN，谁更合适？
避免使用函数处理索引列
避免对索引列计算
使用基于函数的索引
使用HINT
2.使用索引

索引也是需要开销的，所以并不一定要使用索引。
对于数据量较大的表，尽量 使用索引。
程序在UT阶段由于没有实际环境，所以不要使用HINT。
3.减少解析

共享池（Shared Pool）
对于已经运用过的SQL语句，Oracle数据库会将信息存到共享池中，再执行相同的SQL语句时就可以不用再解析了。
原则上，Oracle数据库不会去利用不一样的SQL，哪怕仅仅是多出一个空格，或者大小写的区别。所以为了提高SQL的再利用率，要彻底的遵守编码规范。

使用动态SQL

1、基于规则的优化方式(Rule-Based Optimization，简称为RBO)

 

    优化器在分析SQL语句时,所遵循的是Oracle内部预定的一些规则，对数据是不敏感的。它只借助少量的信息来决定一个sql语句的执行计划，包括：
    1）sql语句本身
    2）sql中涉及到的table、view、index等的基本信息
    3）本地数据库中数据字典中的信息（远程数据库数据字典信息对RBO是无效的）

    例如：我们常见的，当一个where子句中的一列有索引时去走索引。但是需要注意，走索引不一定就是优的，比如一个表只有两行数据，一次IO就可以完成全表的检索,而此时走索引时则需要两次IO,这时全表扫描(full table scan)的效率更优。

 

 

2、基于代价的优化方式(Cost-Based Optimization，简称为CBO)

 

    它是看语句的代价(Cost),通过代价引擎来估计每个执行计划所需的代价，该代价将每个执行计划所耗费的资源进行量化，CBO根据这个代价选择出最优的执行计划。一个查询所耗费的资源可分为三部分：I/O代价、CPU代价、NETWORK代价。I/O是指把数据从磁盘读入内存时所需代价（该代价是查询所需最主要的，所以在优化时一个基本原则就是降低I/O总次数）；CPU代价是指处理内存中数据所需的代价，数据一旦读入内存，当我们识别出我们所要的数据后，会在这些数据上执行排序（sort）或连接（join）操作，这需要消耗CPU资源；对于访问远程节点来说，network代价的花费也是很大的。

    优化器在判断是否用这种方式时,主要参照的是表及索引的统计信息。统计信息给出表的大小、有多少行、每行的长度等信息。这些统计信息起初在库内是没有的，是做analyze后才出现的，很多的时侯过期统计信息会令优化器做出一个错误的执行计划,因些应及时更新这些信息（dbms_stat.analyze）。

    如星型连接排列查询，哈希连接查询，函数索引，和并行查询等一些技术都是基于CBD的。

 

 

3、优化模式包括Rule、Choose、First rows、All rows四种方式：

 

    Rule：基于规则的方式。

    Choolse：默认的情况下Oracle用的便是这种方式。指的是当一个表或或索引有统计信息，则走CBO的方式，如果表或索引没统计信息，表又不是特别的小，而且相应的列有索引时，那么就走索引，走RBO的方式。

    First Rows：它与Choose方式是类似的，所不同的是当一个表有统计信息时，它将是以最快的方式返回查询的最先的几行，从总体上减少了响应时间。

    All Rows:也就是我们所说的Cost的方式，当一个表有统计信息时，它将以最快的方式返回表的所有的行，从总体上提高查询的吞吐量。没有统计信息则走RBO的方式。

 

 

4、设定选用哪种优化模式：

    A、在initSID.ora中设定OPTIMIZER_MODE=RULE/CHOOSE/FIRST_ROWS/ALL_ROWS（默认是Choose）
    B、Sessions级别通过：ALTER SESSION SET OPTIMIZER_MODE=RULE/CHOOSE/FIRST_ROWS/ALL_ROWS
    C、语句级别用Hint（/*+ ... */）来设定

 

 

5、一些常见的问题：

 

  A、为什么表的某个字段明明有索引，但执行计划却不走索引？

    1、优化模式是all_rows的方式 
    2、表作过analyze，有统计信息
    3、表很小，上文提到过的，Oracle的优化器认为不值得走索引。

 

  B、使用CBO时，SQL语句中为什么不能引用系统数据字典表或视图？

    1、因为系统数据字典表都未被分析过，可能导致极差的“执行计划”。

    2、擅自对数据字典表做分析，可能导致死锁，或系统性能严重下降。

 

  C、使用CBO时如何选择表连接方式？

    1、CBO有时会偏重于SMJ和HJ，但在OLTP系统中，NL一般会更好，因为它高效的使用了索引。

    2、SMJ即使相关列上建有索引，最多只能因索引的存在，避免数据排序过程。

    3、HJ由于须做HASH运算，索引的存在对数据查询速度几乎没有影响。

 

  D、使用CBO时，需要注意什么吗？

    1、必须保证为表和相关的索引搜集足够的统计数据， 对数据经常有增、删、改的表最好定期对表和索引进行分析

    2、可用SQL语句：analyze table xxx compute statistics for all indexes

 

  E、为什么有时使用CBO会比较慢？

    1、没有对表或视图进行Analyze

    2、SQL进行CBO时对于没有Analyze的对象会自动进行Analyze，因此造成运行缓慢