OracleDBA性能优化8日游笔记(6)

OracleDBA+性能优化8日游笔记——第四天(四) 2009-12-04 14:58

从第五天开始将会正式进入性能优化的部分

----------------------------------------------------------------------------------------------------------- 四． 网络管理

服务器端管理： 监听器的管理

Conn hr/hr@ABC

ABC = 解析（协议 主机 端口 SID）

单个监听器可以监听多个数据库的链接请求 多个也可以监听一个数据库的链接请求 监听器支持多种网络协议 监听器的名字必须唯一

无论有多少监听器，所有监听器配置信息都放在一个listener.ora 监听器的注册： 静态服务注册 配置lintener.ora 动态服务注册

PMON进程进行注册

OEM对动态注册支持不好

建议即使有动态注册，也最好配静态注册 管理监听器:命令行工具LISRCTL 客户端：配置

Easy connect(解决一次性连接的简单链接，为不常做链接的用户准备)

连接类型：默认（一般选这个），专用模式，共享模式，池中服务器（很少见）

高级：

地址配置：

选择同时连2个地址 选择随即尝试连接

数据库性能优化前瞻--开发人员应注意的几点问题 2009-12-08 17:34

此文章属于我的《OracleDBA+性能优化8日游》系列之一，该系列分为2部分，即：前4天的\部分\与后4天的\性能优化部分\。之所以要在即将开始的\性能优化\之前放出这样一篇文章，是因为\笔记\终究是\笔记\，其中有一些值得介绍的东西都被一带而过，尤其是有搞开发朋友正在面临SQL优化的任务，因此我特别针对一些对开发人员有帮助的优化要点在这里提前做一个略微详细的介绍。。下面进入正文

-----------------------------------------------------------------------------------------------------------------------------------------------

一.对于数据库要优化些什么？

为提高速度而优化的对象也有很多，比如网络，硬件，数据库等等。由于这是一篇面向开发人员的数据库优化的文章，所以这里只关注数据库。

简单的说，数据库的优化实际上就是3部分：对资源使用的优化（内存与磁盘空间），I/O的优化以及对竞争的优化。

其中I/O优化是开发人员重点关注的，因为一条SQL语句的执行速度，主要取决于其执行过程中的I/O次数，不管你怎样理解，对SQL的优化实际上就是对I/O的优化。

其次，对有限内存的使用也是开发者经常考虑的问题，原因很简单，在内存中执行的速度一定比在磁盘中快，而当内存分配不够的时候，系统便会使用磁盘来代替，实际上对磁盘的操作就会消耗多余的I/O，所以这又说明了I/O优化的重要性

最后是竞争的优化，也就是锁的概念，一般来说普通开发者没有处理锁的权限，但他们在程序的设计上可能会考虑到这个问题。 二.优化到什么程度结束

很多人一但开始优化，不在速度上达到极致就不会罢休，实际上，优化是一个找平衡的过程，把一点做到极致就会在其他方面出现缺陷，你可以去看一下百度和谷歌首页的源代码，你会发现所有的代码被写成了一行(我最近一次看的时候其实是4行，但我怀疑是编辑器显示的问题)，并且所有的命名都是很简单的\等，简单的说这就是为了达到最极致的速度而付出的代价，当然还包括省钱，在每天成百上千万的流量面前，多出1个回车或一个字节的字符需要付出的代价都是以\千万倍\为单位计算的。

所以，当一方面的优势最大程度体现出来的同时其缺点没有明显暴露的时候，就是你可以结束优化的时候，另外，出于各方面的考虑，一般达到了客户要求的指标之后就可以停止优化了。 三.慎用触发器

前几天和一位学弟聊天，谈到了他们的数据库老师教给他们的一些知识，其中提到这样一点，\存储过程与触发器都是很常用的数据库技术\。

的确，触发器在理论上也算是很常用的数据库对象，但是，它同时也是一个要尽量少用的对象，原因如下：

1.触发器是\隐式执行\的，它非常不利于维护。什么是隐式执行？简单的说就是它由系统控制而非由你的程序控制。当你执行程序时发现结果与预期不一样，然后去检查你的程序，却在代码中看不到一点问题，检查了3天3夜才发现

原来在系统里还有一个触发器导致了问题出现，这绝对是一件让人非常郁闷的事情。

2.触发器对于性能的影响是相当可观的。触发器针对每一条DML语句都会触发一个事件，这就意味了，你更新1万条数据，触发器就会被执行1万遍，万一触发器中还包含复杂的逻辑判断，万一触发器中还有涉及到对表的查询，万一这个查询还特复杂，万一.......

结论，尽量使用存储过程代替触发器 四.索引的适用范围纠正

网上很多文章对于普通索引的使用范围中，都有一条：查询出来的数据量占整张表数据量的5%以内适合采用索引，最多不能超过10%。

上面那句话其实是有问题的，真正的数字应该是2%以内适合使用索引，最多不要超过5%，具体的计算过程会在以后的性能优化8日游笔记中给出来。 五.\的使用要三思

很多人会在做用于模糊查询的SQL的时候用上\语法，但是这里必须要小心的是，该语法当首字母不确定的时候就不会走索引，所以在写SQL的时候要小心。

六.函数导致的普通索引的失效

这点特别要注意，我在上周刚被这个问题困扰过，比如一个有索引的字段叫a，那么where a = XXX,这种条件可能会走索引，而把该字段包上一个函数则一定会让索引失效，比如where to_char(a) = XXX，解决方法是，如果允许的话可以增加一个函数索引，否则得话，尽量改变你的写法，让to_char(a) = XXX 变成a = XXX。在这里我贴出前几天遇到的问题以及解决方法拿出来做一个例子： 为了节省字数，下面这个SQL省略了SELECT和FROM的部分，只展示WHERE中必要的条件，该条件是对比2个表中的一个叫\的时间字段，比较2个时间的年和月是否相同，这是一个informix数据库的语法： SELECT ... FROM ...

WHERE extend(tpw_spw_c2_sum.first_result,year to month)=extend(te_time.first_result,year to month)

由于被套上了函数，所以原本在first_result字段上的索引失效了，

tpw_spw_c2_sum表的数据量有240万行，此SQL的运行时间长达50秒。 于是为了让它走索引，我将WHERE改成了下面这个样子：

WHERE tpw_spw_c2_sum.first_result between te_time.first_result and extend(to_date((extend(te_time.first_result,year to month)+interval(1) month to month)||'-1 00:00:00'),year to day)-interval(1) day to day 虽然代码比较复杂，但重要的是，我让这个语句走了索引，SQL的执行速度达到了4到8秒的速度

上面是一个修改写法让索引生效的例子，如果增加函数索引和修改写法都无法做到的话(或者水平有限做不到),则可以考虑多增加一个走索引的条件，先通过索引过滤掉一大批的数据，这样也会让速度快一些。 七.注意代码书写规范

Oracle对SQL的执行顺序是：\自内而外，自右而左，自下而上\，先执行最里面的子查询，这点不用说了，当然数据库优化器可能会改变你写的SQL的结构，但这不是这里要讨论的东西。自右而左和自下而上其实是一个东西，比如你将WHERE写成一行，Oracle会先按照最右边的条件过滤，如果用回车将不同条件分成不同行，那么就会优先执行最下面的过滤条件。所以，将能过滤最多数据量的条件放在最下（右）面（最大限度避免重复处理数据），将数据量最多的表放在最上（左）面（FROM a,b 在内部进行表连接的时候b表全表扫描，a表走索引），是一个很不错的习惯。

另外，注意代码规范的理由除了\可读性\外，还有一点，就是对数据库的库高缓存（属于共享池）会有很重要的影响，这里稍微解释下，简单的说就是，数据库会把某些常用SQL语句连同其查出来的数据一起放到内存中，这样可以让下次执行同样的操作的时候大幅度提高速度，但是这样的方便的功能必须要满足一些很苛刻的条件，那就是SQL语句的格式和查询结果必须一模一样，哪怕一个回车、空格或不同的大小写都会导致该SQL不共享,这是规范SQL书写的很重要的一点。

八.不要在代码中设置太长的事务

很多人习惯在处理完所有的事情最后在commit，这个习惯会存在隐患，涉及原因包括回滚段，突发事件等诸多因素，如果事务太长，考虑一下将它分解成小事务，当然了，确实需要很长的事务也不要勉强拆分。 九.尽量将业务处理放在前台业务逻辑层，将数据处理放在后台

这点在itpub论坛上和人家争论了很长时间，有些例子不是举不出来，实在是不想举，这纯粹是个人原因。重点在讨论的中心，有人提倡将所有的事情都仍在数据库以\架空前台\，但实际上我本人不提倡这种做法，尽管现在数据库的功

能相当强大，但原则上应该让数据库做尽量简单的事情，由于这点有争议，所以我只希望各位在遇到实际问题的时候将这个说法作为一个参考，而不是否决其他说法。

但是，无论争论的有多激烈，有一点是当时争论双方的共识，如果你的程序涉及到的大批量的更新操作，要将它放在数据库中去做，比如说前几天一个同事就遇到了这个问题，它用C#编写一个程序，其中有一个用循环去Insert的部分，但是这样循环插入2000条数据就已经让它对速度无法忍耐了，所以来找我写一个存储过程解决问题，这一点要记住，如果涉及到上面相同的情况，一定要把这一部分仍给数据库去做。

十.清空全表使用TRUNCATE代替DELETE

这里涉及到一个高水位线的问题，各位可以自己去试试，往一个表里插20W的数据，然后SELECT *一下，假设用了10秒，那么DELETE FROM table，把所有数据删除掉，再SELECT *一下，会发现明明没数据却还要花10秒钟，原因就是不管有没有数据，全表扫描都会扫描到最高水位线的位置，DELETE是不会重置这个水位线的，具体原因以及什么叫最高水位线这里不做解释。全表清空的语句用\表名\代替\表名\的写法 十一.减少物理读

不太恰当但比较容易的理解是，逻辑读是内存读取数据，物理读从磁盘读取数据，前面说了，内存快磁盘慢，所以要尽量减少物理读，很多人喜欢使用oracle的dual表，但是要记住，所有对dual表的操作都是物理读 十二.慎用DBLINK

尽量避免远端连接，对远端表的访问基本都是全表扫描

OracleDBA+性能优化8日游笔记——第五天(一)性能优化部分 2010-01-06 15:54

已经拖了很久了，从这次开始是性能优化部分

----------------------------------------------------------------------------------------------------------- 第五天

性能优化：

Set autotrace on[off]; --看执行计划 优化思路：知道从哪方面下手 分析：（核心）

收集信息（用工具收集）

百度搜索“70edu”或“70教育网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读，70教育网，提供经典综合文库OracleDBA性能优化8日游笔记(6)在线全文阅读。