Oracle性能收集资料

1、弄清楚你的业务类型 OLTP or OLAP在 Oracle 数据库系统中，很多人没有弄清楚自己的业务类 型到底是什么， 就在开始盲目的寻求优化方法， 而往往是把 OLAP 的方法使用在OLTP上，或者是OLTP的方法使用在OLAPh。这 样的使用，有的时候，对性能没有任何的提高，甚至是大大的影 响了性能，得到适得其反的效果。所以，在优化系统之前，弄清 楚自己的业务类型。OLTP ( 联机事务处理系统)也称为面向交易的处理系统， 其基本特征是顾客的原始数据 可以立即传送到计算中心进行处理， 并在很短的时间内给出处理 结果。这样做的最大优点是可以即时地处理输入的数据， 及时地 回答。也称为实时系

2、统 (Real time System) 。衡量联机事务处理 系统的一个重要性能指标是系统性能， 具体体现为实时响应时间 (Response Time) ，即用户在终端上送入数据之后，到计算机对 这个请求给出答复所需要的时间。OLAP（联机分析处理系统）联机分析处理（OLAP）的概念最早是由关系数据库之父于1993年提出的，他同时提出了关于 OLAP的12条准则。OLAFP勺提出引起了很大的反响，OLAP作为一类产品同联机事务处理（OLTP）明显区分开来。当今的数据处理大致可以分成两大类：联机事务处理OLTP（on-li ne tran sacti on process ing）、联机分析处理

3、 OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAF是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。OLTP与 OLAP之间的比较:OLTPOLAP用户操作人员，低层管理人员决策人员，高级管理人员功能日常操作处理分析决策DB设计面向应用面向主题数据最新的，细节的，二维的，分立的历史的，聚集的，多维的，集成的存取规模读/写数条（甚至数百条）记录读上百万（甚至上亿）条记录操作频度非常频繁（以秒计）比较稀松（以小时甚至以周计）工作单位严格的事务复杂

4、的查询用户数数百个-数千万个数个-数百个DB大小100MB-GB100GB-TB1、什么是OLTPOLTP,也叫联机事务处理 (Online TransactionProcess in g)，表示事务性非常高的系统，一般都是高可用的在 线系统，以小的事务以及小的查询为主，评估其系统的时候，一 般看其每秒执行的transaction以及execute sql的数量。在这样的系统中，每秒处理的transaction 往往超过几百个，或者是 几千个，select语句的执行量每秒几千甚至几万个。 典型的OLTP 系统如电子商务系统，银行，证卷等等，如美国ebay的业务数据库，就是很典型的 OLTP数据

5、库。OLTP系统最容易出现的瓶颈就是CPU与磁盘子系统。cpu则取决于逻辑读以及内部调用，如函数等等。一个执行 频繁的SQL语句，如果每个语句可以减少很少的逻辑读，也相当于优化了一些逻辑读很差的大型语句。很多人不感觉不到这里的作用，觉得一个语句几十个逻辑读，执行时间基本为0，就不需要优化了，其实，只要他的执行次数非常频繁，而且有优化的余地，就一定要优化，如减少一定的逻辑读或者降低执行次数，都 是优化方法。另外，一些计算性的函数，如 sum， count ， decode 被非常频繁的使用，也是非常消耗 cpu 的，我遇到一个系统，因 为一个 sql 语句，大量的使用了 sum 与 decode

6、 进行行列转换， 结果这一个语句就耗费了整个机器一半以上的CPU。那么，在一般的OLTP系统中，如果不考虑我上面说 的函数问题，那么，逻辑读乘以执行次数，决定了 cpu 的消耗程 度，如一个语句，每秒执行次数为 500 次，每个逻辑读为 15， 但是，通过优化，能让每个语句的逻辑读从15 降到 10，那么，每秒的逻辑读就可以减少 500*5=2500 个，其实就是相当于优化 了一个执行频率为每秒 1 次，每次逻辑读为 2500 个的语句（注 意， 2500 个逻辑读，在 oltp 系统是非常差的语句）。再如，假 定一个1GHZ勺cpu每秒能正常处理的逻辑读是 100,000个，如 果是 10

7、个逻辑读一个的语句， 每秒可以处理 10,000 个，而 1000 个逻辑读一个的语句，每秒则只能处理 100个。同以上道理，物理读乘以执行次数，则决定了存储子系统的处理能力，在一个OLTF环境中，物理读一般都是db file seque ntial read决定的，也就是单块读，一个典型的OLTP系统， db file sequential read应当基本等于磁盘子系统的读的IOPS。而磁盘子系统的IOPS处理能力，与cache命中率以及磁 盘个数有很大的关系。我的一些文章中，也分析到了这些问题， 如一个15K转速的磁盘，每秒最多能处理的iops达到150个，基本就是极限了，如果 cach

8、e 不命中，那么 100 个磁盘，最多能 处理的IOPS仅仅是15000个（但是，实际上，还基本达不到这 个值）。OLTP最常用的技术就是cache技术与btree索引，cache 决定了很多语句不需要从磁盘子系统获得数据， 所以， web cache与oracle data buffer 对OLTP系统是很重要的。另外， 在索引使用方面，语句是越简单越好，这样执行计划也稳定，而 且一定要使用绑定变量，减少语句解析，尽量减少关联。其它方 面，基本不使用分区技术，MV技术，并行技术以及位图索引，因为并发量很高，批量更新可能要尽量快速提交避免阻塞的发 生。在 ebay 的数据库设计中，有一个很重要

9、的点就是，数据库只负责存放数据，业务逻辑尽量在业务层实现，因为 数据库扩展是困难的，而应用服务器扩展是简单的。其实，也就 是说，在高可用的OLTF环境中，数据库使用越简单的功能越好。2、什么是 OLAPOLAP， 也 叫 联 机 分 析 （Online AnalyticalProcess in g），有的时候也叫DSS决策支持系统，就是我们说的 数据仓库。在这样的系统中，语句的执行量不是考核标准，因为 一个语句的执行时间可能会非常长， 读取的数据也非常多。 所以， 这样的系统中，考核的标准往往决定于磁盘子系统的吞吐量。磁盘子系统的吞吐量则直接取决于磁盘的个数， 这个时候， cache 基本是没

10、有效果的，这个时候数据库的读写基 本上是 db file scattered read 与 direct path read/write 。 在我前面的一些文章中描述过，如果一个15K的磁盘的10量每秒13M那么，100个磁盘，最多能提供的吞吐量则是 1300M/S （实际上，也基本达不到这个值）。如果磁盘个数足够的话，还 需要考虑采用比较大的带宽，如 4GB的光纤接口。在OLAP系统中，常使用的技术有分区技术，并行技术。如分区技术可以使得一些大表的扫描变得很快 （只扫描单个 分区），而且方便管理。另外，如果分区结合并行的话，也可以 使得整个表的扫描也会变得很快。 并行技术除了与分区技术结合

11、外，在 oracle 10g 中，与 rac 结合实现多节点的同时扫描，效 果也非常不错，把一个任务，如 select 的全表扫描，平均的分 派到多个 rac 的节点上去。在OLAP系统中，不需要使用绑定变量，因为整个系统的执行量很少，分析时间对于执行时间来说，可以忽略，而且 避免出现错误的执行计划。 但是OLAP中可以大量使用位图索引， 物化视图，对于大的事务，尽量的寻求速度上的优化，没有必要 象OLTP需要快速提交，甚至要刻意减慢执行的速度。3、总结特别是在高可用的 OLTF环境中，不要盲目的把OLAP的技术拿过来用， 如分区技术， 如果不是大范围的使用了分区关 键字作为 where 条件，而采用其它的字段作为 where 条件，那么， 如果是本地索引， 你将不得不扫描多个索引， 而性能变的更为低 下。如果是全局索引，那分区的意义又何在，只是多出一份分区 技术的 license 而已。并行技术也是如此，一般是在大型任务的时候才使 用，好比说， 实际生活中， 一个比较大型的工作， 如翻译一本书， 你可以先安排多个人， 每个人翻译不同的章节， 这样是可以提高 翻译速度，但是，你现在只是翻译一页，你也去分配不同的人翻译不