弄清楚你的业务类型——OLTPorOLAP在Oracle数据库系统中，很多人没有弄清楚自己的业务类型到底是什么，就在开始盲目的寻求优化方法，而往往是把OLAP的方法使用在OLTP上，或者是OLTP的方法使用在OLAP上。这样的使用，有的时候，对性能没有任何的提高，甚至是大大的影响了性能，得到适得其反的效果。所以，在优化系统之前，弄清楚自己的业务类型。OLTP(联机事务处理系统）也称为面向交易的处理系统，其基本特征是顾客的原始数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果。这样做的最大优点是可以即时地处理输入的数据，及时地回答。也称为实时系统(RealtimeSystem)。衡量联机事务处理系统的一个重要性能指标是系统性能，具体体现为实时响应时间(ResponseTime)，即用户在终端上送入数据之后，到计算机对这个请求给出答复所需要的时间。。OLAP（联机分析处理系统）联机分析处理(OLAP)的概念最早是由关系数据库之父E.F.Codd于1993年提出的，他同时提出了关于OLAP的12条准则。OLAP的提出引起了很大的反响，OLAP作为一类产品同联机事务处理(OLTP)明显区分开来。当今的数据处理大致可以分成两大类：联机事务处理OLTP（on-linetransactionprocessing）、联机分析处理OLAP（On-LineAnalyticalProcessing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。OLTP与OLAP之间的比较:OLTPOLAP用户操作人员，低层管理人员决策人员，高级管理人员功能日常操作处理分析决策DB设计面向应用面向主题数据最新的，细节的，二维的，分立的历史的，聚集的，多维的，集成的存取规模读/写数条（甚至数百条）记录读上百万（甚至上亿）条记录操作频度非常频繁（以秒计）比较稀松（以小时甚至以周计）工作单位严格的事务复杂的查询用户数数百个-数千万个数个-数百个DB大小100MB-GB100GB-TB1、什么是OLTPOLTP，也叫联机事务处理(OnlineTransactionProcessing)，表示事务性非常高的系统，一般都是高可用的在线系统，以小的事务以及小的查询为主，评估其系统的时候，一般看其每秒执行的transaction以及executesql的数量。在这样的系统中，每秒处理的transaction往往超过几百个，或者是几千个，select语句的执行量每秒几千甚至几万个。典型的OLTP系统如电子商务系统，银行，证卷等等，如美国ebay的业务数据库，就是很典型的OLTP数据库。OLTP系统最容易出现的瓶颈就是CPU与磁盘子系统。cpu则取决于逻辑读以及内部调用，如函数等等。一个执行频繁的SQL语句，如果每个语句可以减少很少的逻辑读，也相当于优化了一些逻辑读很差的大型语句。很多人不感觉不到这里的作用，觉得一个语句几十个逻辑读，执行时间基本为0，就不需要优化了，其实，只要他的执行次数非常频繁，而且有优化的余地，就一定要优化，如减少一定的逻辑读或者降低执行次数，都是优化方法。另外，一些计算性的函数，如sum，count，decode被非常频繁的使用，也是非常消耗cpu的，我遇到一个系统，因为一个sql语句，大量的使用了sum与decode进行行列转换，结果这一个语句就耗费了整个机器一半以上的CPU。那么，在一般的OLTP系统中，如果不考虑我上面说的函数问题，那么，逻辑读乘以执行次数，决定了cpu的消耗程度，如一个语句，每秒执行次数为500次，每个逻辑读为15，但是，通过优化，能让每个语句的逻辑读从15降到10，那么，每秒的逻辑读就可以减少500*5=2500个，其实就是相当于优化了一个执行频率为每秒1次，每次逻辑读为2500个的语句（注意，2500个逻辑读，在oltp系统是非常差的语句）。再如，假定一个1GHZ的cpu每秒能正常处理的逻辑读是100,000个，如果是10个逻辑读一个的语句，每秒可以处理10,000个，而1000个逻辑读一个的语句，每秒则只能处理100个。同以上道理，物理读乘以执行次数，则决定了存储子系统的处理能力，在一个OLTP环境中，物理读一般都是dbfilesequentialread决定的，也就是单块读，一个典型的OLTP系统，dbfilesequentialread应当基本等于磁盘子系统的读的IOPS。而磁盘子系统的IO...
