首页 > 数据库 > Oracle > ORACLE高效设计之我见
ORACLE高效设计之我见
读Thomas kyte《Effiective Oracle by Design》
我读了一本书的名字是《Effiective Oracle by Design》,,这本书是由久负盛名的Oracle顶级专家Thomas Kyte所著。他也是asktom.oracle.com网站的创立者。本书对Oracle的许多重要的概念和特性进行了独到的讨论。对如何设计一个好的ORACLE应用进行了深入的剖析。下面我对每一章讲述的内容做一个概括并提出自己的看法。
第一章主要讲述构建oracle应用的正确方法与态度,涉及的技术细节较少。本章论述数据库开发人员和DBA之间工作的配合和区别。作者建议适当阅读Oracle官方文档以便对Oracle有个整体的认识并给出了具体的阅读建议。阐明了学习Oracle的方法,多做具有代表性的测试、并发测试、根据实际情况测试、多使用Oracle的特性以更好的发挥Oracle强大的功能。要敢于怀疑权威,用事实说话,用实验说话。
第二章主要介绍了作者用于观察性能好坏的一些方法和工具。并对这些方法和工具的使用做了说明,并对观察性能的各项指标数据做了详细的说明。本书在后面我们做实验时,经常使用这些工具。工具包括explain plan、autotrace、tkprof、runstats、statspack。
第三章主要对体系结构选择提出了作者的看法。本章从达到高并发性、高效地处理存储空间、利用并行操作三个方面进行了探讨。应该使用专用服务器还是共享服务器?事实上,据我的经验,因为业务现在在访问数据库时,有数据库连接共享池的使用,所以在数据库层面,使用共享服务器就不能发挥它的优势了,所以,大多数的系统,使用专用服务器是合适的。本章还对是否应该使用RAC(Real Application Clusters)进行了分析;也对使用分区表的优点提高可用性、易于管理、提高性能方面进行了分析。本文还提到了并行查询,并行查询并非对非并行查询快多少个并行度,事实上,并行处理的开销也是很大的,对于一个快速的操作(比如10秒以下),使用并行操作反而会更慢。
第四章高效的管理。本章对Oracle的一些管理方面的技术进行了分析。用SPFILE来管理数据库参数文件相比用PFILE管理来说更安全和高效,SPFILE不能直接编辑,只能通过命令来修改,PFILE是一个文本文件,可以任意修改,相对更不安全。在生产环境下一定要采用归档模式,使用RMAN自动进行实时备份。遵循这些原则,在发生意外时,可能极大的减少损失。可以说,DBA的最重要的职责是建立完备的数据库安全系统,DBA不能犯错的事情就是备份和恢复,系统慢还可以调优,但是丢失数据的损失是难以弥补的。本章对表空间的管理方式也进行了分析,ORACLE有字典管理表空间方式(DMT)和本地管理表空间(LMT)。字典管理是用ORACLE内部的表来维护和分配表空间,本地管理表空间在数据文件本身使用一定的标识来标识表空间是否空闲,本地管理表空间比字典管理表空间的优势是全方位的,我没有发现有不使用本地管理表空间的理由。 本章还讨论存储参数PCTFREE和PCTUSED参数对空间分配的影响,回退表空间的管理和undo_retention参数的设置。undo_retention这个参数对OLTP小事务量的业务基本没有影响,但对长时间的查询,如果需要林回退段找的数据过早的被清除,则会引发ORA1555错误。所以这个参数主要是根据你最长的查询时间来设置的。事实是,设置了足够长也不能保证不会产生ORA1555错误,因为undo_retention设置和时间是个建议保留时间,并没有强制的约束力,如果新的事务需要回退表空间,则回退段的空间会提前清除。
第五章主要讲SQL语句的处理。本章首先介绍了SQL语句执行的过程并针对SQL语句执行过程进行了优化。SQL语句执行一般有分析、优化、生成执行计划、语句执行四个步骤。其中分析阶段语法语义检查、共享池检查,硬分析或软分析。硬分析的资源消耗很大,所以我们应该尽量避免不必须的硬分析。避免硬分析做为开发人员来说,最主要的是做到写代码时做到绑定变量。比如select * from t_userinfo where phonenumber = ‘13808888888’,就不是绑定变量,应该写成select * from t_userinfo where phonenumber = :var_phonenumber,这样,就可以避免硬解析。还有也几个参数shard_pool size大小,session_cached_cursors,open_cursors对是否分析、采用哪种分析也有影响。解析方式有四种,硬解析、软解析、快速解析和不分析四种,硬解析是就未能在SQL池中命中,软解析是指能够在SQL池中命中,快速解析是否在PGA的session cache list池中命中,不分析在具体业务中比较罕见,主要是在关闭游标后(事实上ORACLE未真正关闭)反复打开时。所以,事实上,我们在开发时一定要做到绑定变量,就基本能够避免SQL解析和SQL解析内存分配出错的问题。
第6章主要论述了ORACLE支持的两个优化器,基于规则(RBO)和基于成本(CBO)的分析。基于规则是指ORACLE根据自己的已知的规则来确定生成查询计划。比如查询语句,两个谓词短语,都有索引,究竟oracle查询时使用哪个索引呢? 比如,一个字段是number型,一个是char型,据规则的话,会首先使用number型的索引,事实上number型的索引可能很大,也有可以区分度不好,查询效率并不好,可以用char字段来效率更高。这就是基于规则的缺点,优点是查询计划是固定的,不会变化。CBO则刚好相反,它事先根据已有对表的统计信息,认为自己可以判断出最优的查询计划,缺点则是查询计划容易变化。所以cbo首先要保证有较新的统计信息。Cbo是oracle的一个大力发展的方向,在oracle 10G以后,rbo优化器将慢慢被oracle摒弃。本文还讲解了几个会影响CBO选择查询计划的几个参数,如optimizer_index_cost_adj,optimizer_index_caching,以用它们的使用场合。
第七章讲述了高效的模式设计。本章主要介绍了ORACLE所具有的一些独特的高效的特性。比如集群表、索引组织表、外部表、反向索引、树群索引、函数索引、域索引技术。我主要对函数索引和反向索引方面有使用的体会,其它技术初步了解了一下,并没有真正使用并且经过测试的技术。函数索引个人理解是等价于在表中增加了一列,不过这一列并不用自己手动去维护,这一列是通过一定的函数计算出来,查询时,把这些值保存在索引中,加快查询的速度。反向索引是为了避免那些自增的字段,这样话,每次都是在索引树的右边插入数据,导致树的分裂频率增加,把数据反向后保存在索引当中。
第八章是本书的重点。本章讨论了编写高效的SQL所需要的知识。本章主要内容包括数据库访问数据的路径、表之间的连接方法、SQL语句的一些ORACLE所独具的特性。访问路径主要包括全表扫描、ROWID访问、索引扫描、群扫描几种方式。连接主要有嵌套循环、散列连接、排序合并、笛卡儿连接、反连接、全外部连接几种。这些访问方式和连接方式本身没有谁优谁劣,要根据各种自身的情况,选择合适的方式。比如,对于小于300行的表,就没有必要通过索引来访问,因为300行的表,可能只占用一个数据块,如果通过索引的话,就要访问索引块、然后通过ROWID访问数据块,至少要访问3个数据块。联接方面对于那种一个数据量的表和一个小数据量的表,并且返回大数据的数据时,此时用HASH连接非常高效。比如对日志表的联接查询。ORACLE的一些特性如ROWNUM、标量查询、分析函数都是ORACLE非常有用和高效的特性,可以减少很大的工作量。比如要查询一个公司各个部门的工资总和、各个部门的人数总和等等查询,通常情况下,要写两次查询才能完成,至少两个全表扫描,但使用分析函数就可以做到一个全表扫描。
第九章写的是高效的PL/SQL程序设计。PL/SQL是由基本的SQL组成的,高效的SQL基本就决定了整个业务是否高效。这章主要讲了根据ORACLE的特性,编写代码的一些良好的习惯。
Thomas Kyte还写了《Expert one-on-one Oracle》,《9i and 10g programming Techniques and Solutions》这些书,都是了解ORACLE的经典书籍,写的深入浅出,不失为经典之作。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/164345/viewspace-1000922/ ,如需转载,请注明出处,否则将追究法律责任。