网志栈编辑推荐
汇聚Oracle专家集体智慧?
； ； ； 内容贴近实战，讲解透彻精彩?
； ； ； DBA修炼内力必读秘籍
；
内容简介
本书由15位知名技术专家联手打造，每位作者分别用一章的篇幅介绍他们最擅长的PL/SQL相关主题，涵盖了PL/SQL开发的方方面面。本书作者要么是Oracle社区中坚分子，要么是大名鼎鼎的OakTable成员，而且经常活跃在Oracle技术培训第一线，对PL/SQL均有着深入透彻的理解，对解释复杂问题有着简单独到的方法。一册在手，众多PL/SQL牛人的真知灼见尽收眼底，你还等什么？
本书着重介绍了PL/SQL*、最实用的特性，从什么该做和什么不该做、怎么做对，以及怎么做更有效率、效果更好等三个部分全面阐释了PL/SQL相关的各个主题。而且，每一章都配有非常贴切的示例代码、跟踪图以及输出结果，辅以深入浅出的讲解，令人在恍然大悟之后不禁拍案叫绝。各章内容均涵盖了PL/SQL实际开发中的*实践，反映了作者多年积累的经验和教训，其价值非同一般。
本书适合具有一定PL/SQL经验的读者学习参考。
作者简介
目录
第1章 避免误用
1.1 逐行处理
1.2 嵌套的逐行处理
1.3 查找式查询
1.4 对DUAL的过度访问
1.4.1 日期的算术运算
1.4.2 访问序列
1.4.3 填充主—从行
1.5 过多的函数调用
1.5.1 不必要的函数调用
1.5.2 代价高昂的函数调用
1.6 数据库链接调用
1.7 过度使用触发器
1.8 过度提交
1.9 过度解析
1.10 小结
第2章 动态SQL：处理未知
2.1 动态SQL的三种方式
2.1.1 本地动态SQL
2.1.2 动态游标
2.1.3 DBMS_SQL
2.2 动态思考的样例
2.3 安全问题
2.4 性能和资源利用率
2.4.1 反模式
2.4.2 比较动态SQL的实现
2.5 对象的依赖关系
2.5.1 负面影响
2.5.2 正面影响
2.6 小结
第3章 PL/SQL和并行处理
3.1 为什么需要并行处理
3.2 影响并行处理的定律
3.3 大数据的崛起
3.4 并行与分布式处理
3.5 并行硬件体系结构
3.6 确定目标
3.6.1 加速
3.6.2 按比例扩展
3.6.3 并行度
3.7 用于并行处理的候选工作负载
3.7.1 并行和OLTP
3.7.2 并行和非OLTP工作负载
3.8 MapReduce编程模型
3.9 在使用PL/SQL之前
3.10 可用于并行活动的进程
3.11 使用MapReduce的并行执行服务器
3.11.1 管道表函数
3.11.2 指导
3.11.3 并行管道表函数小结
3.12 小结
第4章 警告和条件编译
4.1 PL/SQL 警告
4.1.1 基础
4.1.2 使用警告
4.1.3 升级警告为错误
4.1.4 忽略警告
4.1.5 编译和警告
4.1.6 关于警告的结束语
4.2 条件编译
4.2.1 基础
4.2.2 正在运行代码的哪部分
4.2.3 预处理代码的好处
4.2.4 有效性验证
4.2.5 控制编译
4.2.6 查询变量
4.2.7 关于条件编译的结束语
4.3 小结
第5章 PL/SQL单元测试
5.1 为什么要测试代码
5.2 什么是单元测试
5.2.1 调试还是测试
5.2.2 建立测试的时机
5.3 单元测试构建工具
5.3.1 utPLSQL：使用命令行代码
5.3.2 Quest Code Tester for Oracle
5.3.3 Oracle SQL Developer
5.4 准备和维护单元测试环境
5.4.1 创建单元测试资料档案库
5.4.2 维护单元测试资料档案库
5.4.3 导入测试
5.5 构建单元测试
5.5.1 使用单元测试向导
5.5.2 创建第一个测试实施
5.5.3 添加启动和拆除进程
5.5.4 收集代码覆盖率统计信息
5.5.5 指定参数
5.5.6 添加进程验证
5.5.7 保存测试
5.5.8 调试和运行测试
5.6 扩大测试的范围
5.6.1 创建查找值
5.6.2 植入测试实施
5.6.3 创建动态查询
5.7 支持单元测试功能
5.7.1 运行报告
5.7.2 创建组件库
5.7.3 导出、导入和同步测试
5.7.4 构建套件
5.8 从命令行运行测试
5.9 小结
第6章 批量SQL操作
6.1 五金商店
6.2 设置本章的例子
6.3 在PL/SQL中执行批量操作
6.3.1 批量获取入门
6.3.2 三种集合风格的数据类型
6.3.3 为什么要自找麻烦
6.3.4 监控批量收集的开销
6.3.5 重构代码以使用批量收集
6.4 批量绑定
6.4.1 批量绑定入门
6.4.2 度量批量绑定性能
6.4.3 监视内存的使用
6.4.4 11g中的改进
6.5 批量绑定的错误处理
6.5.1 SAVE EXCEPTIONS和分批操作
6.5.2 LOG ERRORS子句
6.5.3 健壮的批量绑定
6.6 大规模集合的正当理由
6.7 真正的好处：客户端批量处理
6.8 小结
第7章 透识你的代码
7.1 本章内容取舍
7.2 自动代码分析
7.2.1 静态分析
7.2.2 动态分析
7.3 执行分析的时机
7.4 执行静态分析
7.4.1 数据字典
7.4.2 PL/Scope
7.5 执行动态分析
7.5.1 DBMS_PROFILER和DBMS_TRACE
7.5.2 DBMS_HPROF
7.6 小结
第8章 合同导向编程
8.1 契约式设计
8.1.1 软件合同
8.1.2 基本合同要素
8.1.3 断言
8.1.4 参考文献
8.2 实现PL/SQL合同
8.2.1 基本的ASSERT程序
8.2.2 标准的包本地断言
8.2.3 使用ASSERT执行合同
8.2.4 其他改进
8.2.5 合同导向函数原型
8.3 示例：测试奇数和偶数
8.4 有用的合同模式
8.4.1 用NOT NULL输入且输出NOT NULL
8.4.2 函数返回NOT NULL
8.4.3 布尔型函数返回NOT NULL
8.4.4 检查函数：返回TRUE或ASSERTFAIL
8.5 无错代码的原则
8.5.1 严格地断言先决条件
8.5.2 一丝不苟地模块化
8.5.3 采用基于函数的接口
8.5.4 在ASSERTFAIL处崩溃
8.5.5 对后置条件进行回归测试
8.5.6 避免在正确性和性能之间取舍
8.5.7 采用Oracle 11g优化编译
8.6 小结
第9章 从SQL调用PL/SQL
9.1 在SQL中使用PL/SQL函数的开销
9.1.1 上下文切换
9.1.2 执行
9.1.3 欠理想的数据访问
9.1.4 优化器的难点
9.1.5 读一致性陷阱
9.1.6 其他问题
9.2 降低PL/SQL函数的开销
9.2.1 大局观
9.2.2 使用SQL的替代品
9.2.3 减少执行
9.2.4 协助CBO
9.2.5 调优PL/SQL
9.3 小结
第10章 选择正确的游标
10.1 显式游标
10.1.1 解剖显式游标
10.1.2 显式游标和批量处理
10.1.3 REF游标简介
10.2 隐式游标
10.2.1 解剖隐式游标
10.2.2 隐式游标和额外获取的理论
10.3 静态REF游标
10.3.1 详细的游标变量限制清单
10.3.2 客户端和REF游标
10.3.3 有关解析的话题
10.4 动态REF游标
10.4.1 例子和最佳用法
10.4.2 SQL注入的威胁
10.4.3 描述REF游标中的列
10.5 小结
第11章 大规模PL/SQL编程
11.1 将数据库作为基于PL/SQL的应用服务器
11.1.1 案例研究：Avaloq银行系统
11.1.2 在数据库中使用PL/SQL实现业务逻辑的优势
11.1.3 用数据库作为基于PL/SQL的应用程序服务器的限制
11.1.4 软因素
11.2 大规模编程的要求
11.3 通过规范实现一致性
11.3.1 缩写词
11.3.2 PL/SQL标识符的前缀和后缀
11.4 代码和数据的模块化
11.4.1 包和相关的表作为模块
11.4.2 含有多个包或子模块的模块
11.4.3 模式作为模块
11.4.4 在模式内部模块化
11.4.5 用模式模块化与在模式内模块化的比较
11.5 使用PL/SQL面向对象编程
11.5.1 使用用户定义类型的面向对象编程
11.5.2 使用PL/SQL记录面向对象编程
11.5.3 评估
11.6 内存管理
11.6.1 测量内存使用
11.6.2 集合
11.7 小结
第12章 渐进式数据建模
12.1 从二十年的系统开发中总结的经验
12.2 数据库和敏捷开发
12.3 渐进式数据建模
12.4 重构数据库
12.5 通过PL/SQL创建访问层
12.6 敏捷宣言
12.7 用PL/SQL进行渐进式数据建模
12.7.1 定义接口
12.7.2 思考可扩展性
12.7.3 测试驱动开发
12.7.4 明智地使用模式和用户
12.8 小结
第13章 性能剖析
13.1 何谓性能
13.1.1 功能需求
13.1.2 响应时间
13.1.3 吞吐量
13.1.4 资源利用率
13.1.5 性能是功能的一种
13.2 什么是剖析
13.2.1 顺序图
13.2.2 概要文件之神奇
13.2.3 性能剖析的好处
13.3 性能测量
13.3.1 这个程序为什么慢
13.3.2 测量嵌入
13.3.3 识别
13.3.4 条件编译
13.3.5 内建的剖析器
13.3.6 扩展的SQL跟踪数据（事件10046）
13.3.7 针对Oracle的测量工具库（ILO）
13.4 问题诊断
13.4.1 R方法
13.4.2 ILO示例
13.4.3 剖析示例
13.5 小结
第14章 编码规范和错误处理
14.1 为什么要制订编码规范
14.2 格式化
14.2.1 大小写
14.2.2 注释
14.2.3 比较
14.2.4 缩进
14.3 动态代码
14.4 包
14.5 存储过程
14.5.1 命名
14.5.2 参数
14.5.3 调用
14.5.4 局部变量
14.5.5 常量
14.5.6 类型
14.5.7 全局变量
14.5.8 本地存储过程和函数
14.5.9 存储过程元数据
14.6 函数
14.7 错误处理
14.7.1 错误捕获
14.7.2 错误报告
14.7.3 错误恢复
14.7.4 先测试再显示
14.8 小结
第15章 依赖关系和失效
15.1 依赖链
15.2 缩短依赖链
15.3 数据类型引用
15.4 用于表修改的视图
15.5 把组件添加到包
15.6 依赖链中的同义词
15.7 资源锁定
15.8 用触发器强制执行依赖
15.9 创建最初禁用的触发器
15.10 小结
前沿
作为图书编辑，我一般满足于在幕后做好自己的编辑工作，很少站到前台来为我负责编辑的图书作序。但是，这次我却破例了。因为我也曾做过开发，这本书的内容勾起了我的很多回忆。
本书旨在教你如何有效地使用PL/SQL。它不是描述语法的书，而是介绍如何把语法及其特性与良好的开发实践相结合，创建更具有可靠性、可扩展性的应用，并使之具备长期可维护性。
不管使用什么工具，首先需要明白的是在什么情况下使用它比较合适。在本书的开篇章节“避免误用”中，RiyajShamsudeen巧妙地回答了何时使用PL/SQL这一问题。我把这一章放在本书的开始，也是因为我个人的经历：那是在20世纪90年代末，我进行了最成功的一次性能优化，那次我把客户端PC上的一堆过程代码改写为一个SQL语句以后，一个作业的运行时间从超过36小时缩短到仅仅几分钟。虽然PL/SQL不是导致性能问题的罪魁祸首，但是我得到了一条经验——基于集合的方法（如果有可能）通常优于过程性代码。
MichaelRosenblum紧接着写了动态SQL那一章，其内容相当精彩。他说明了如果只有到最终运行时才知道所要运行的SQL语句到底是什么，那么该如何编写代码。这使我想起20世纪90年代初的一段经历，那时我在陶氏化学公司利用Rdb的扩展动态游标功能集，为一个医疗记录系统写数据装载应用程序。我感觉那是我开发过的最有趣的应用程序之一。
免费在线读
避免误用
Riyaj Shamsudeen
感谢您购买本书。PL/SQL是你值得拥有的好工具，不过，你应当理解PL/SQL并不适用于所有场景。本章将讲述何时使用PL/SQL编写应用程序，怎样编写可扩展的代码，更重要的是，何时不使用PL/SQL编写代码。滥用某些PL/SQL的结构会导致不可扩展的代码。本章将讨论大量的案例，它们因误用PL/SQL而不可扩展。
PL/SQL 与 SQL
SQL是一门集合处理的语言，如果以集合级别的思维编写SQL语句,则会使其具有更好的可扩展性。PL/SQL是过程语言，而SQL语句可以嵌入到PL/SQL代码中。
SQL语句在SQL执行器（也就是通常说的SQL引擎）中执行。PL/SQL语句则由PL/SQL引擎执行。PL/SQL的威力在于能将PL/SQL的过程化数据处理能力和SQL的集合处理能力结合起来。
1.1 逐行处理
在一个典型的逐行处理程序中，代码首先打开一个游标，然后遍历从游标返回的行，并且处理每一行数据。这种基于循环的处理方式是非常不赞成使用的，它会导致不可扩展的代码。代码清单1-1显示了一个使用这种结构的例子。
代码清单1-1 逐行处理
在代码清单1-1中，程序声明了一个游标c1，然后用游标for循环隐式地打开了这个游标，对从游标c1取出的每一行，程序查询customers表，并把first_name和last_name的值填充到变量，随后插入一行数据到top_sales_customers表。
代码清单1-1的编程方法很有问题。即使在循环中调用的SQL语句是高度优化的，程序的执行还是会消耗大量时间。假设查询customers表的SQL语句消耗0.1秒，INSERT语句也消耗0.1秒，那么在循环中每次执行就要0.2秒。如果游标c1取出了100000行，那么总时间就是100 000乘以0.2秒，即20000秒，也就是大约5.5小时。很难去优化这个程序的结构。基于显而易见的理由，TomKyte把这种处理方式定义为慢之又慢的处理（slow-by-slow processing）。
注意本章的例子采用SH模式（schema），这是Oracle公司提供的范例模式之一。要安装这个范例模式，Oracle提供了安装软件。可以从http://download.oracle.com/otn/solaris/oracle11g/R2/solaris.sparc64_11gR2_examples.zip下载Solaris平台11gR2版本的样例软件。软件解压缩后的目录中含有安装说明。Oracle网站也提供了其他平台和版本的范例软件的Zip压缩包。
代码清单1-1的代码还有一个固有的问题。从PL/SQL的循环中调用的SQL语句会反复在PL/SQL引擎和SQL引擎之间切换执行，这种两个环境之间的切换称作上下文切换。上下文切换增加了程序运行的时间，并增加不必要的CPU开销。你应当通过消除或减少这种两个环境之间的切换来减少上下文切换的次数。
一般应当禁止逐行处理，更好的编程实践是把代码清单1-1的程序转换成一个SQL语句。代码清单1-2重写了代码，完全避免了PL/SQL。
代码清单1-2 重写逐行处理的代码
代码清单1-2除了解决逐行处理的缺陷以外，还有更多的优势。重写后的SQL语句可以使用并行执行来调优，使用多个并行执行进程可以大幅地减少执行时间。并且，代码变得简明且可读性强。
注意如果将PL/SQL的循环代码重写为连接（join），需要考虑重复问题。如果在customers表中cust_id列有重复值，那么重写后的SQL语句取回的行比你想要的行多。不过，在这个特定的例子中，customers表的cust_id列上有主键，因此在cust_id列上使用等值连接不存在重复的危险。
1.2 嵌套的逐行处理
在PL/SQL语言中游标可以嵌套使用。首先将数据从一个游标中取出，然后将这些值传给另一个游标，即二级游标，再从二级游标取值传给三级游标，以此类推，这是很常见的编程方法。但是如果游标嵌套很深，这种基于循环的代码导致的性能问题就会加剧。由于游标嵌套，SQL执行的次数大量增加，导致程序运行时间更长。
在代码清单1-3中，c1、c2和c3是嵌套游标。游标c1是顶级游标，从表t1取得数据，c2是开放游标，传递从游标c1取得的值，c3也是开放游标，传递游标c2取得的值。有一个UPDATE语句对游标c3返回的每一行执行一次。尽管UPDATE语句已经优化为执行一次只要0.01秒，但程序的性能还是会由于深度嵌套游标而难以忍受的。假设游标c1、c2和c3分别返回20、50和100行，那么上述代码需要循环100000行，程序的总执行时间超过了1000秒。对这类程序的调优通常需要完全重写它。
代码清单1-3 用嵌套游标逐行处理
代码清单1-3中代码的另一个问题在于先执行一个UPDATE语句。如果UPDATE语句产生了no_data_found异常，那么再执行一个INSERT语句。这种类型的问题可以利用MERGE语句从PL/SQL转到SQL引擎处理。
从概念上讲，代码清单1-3中的三重循环表示表t1、t2和t3之间的等值连接。代码清单1-4展示了根据上述逻辑改写的使用表别名t的SQL语句。UPDATE和INSERT逻辑的结合用MERGE语句代替，MERGE语法提供了更新存在的行和插入不存在的行的功能。
代码清单1-4 用MERGE语句重写逐行处理
不要在PL/SQL语言中编写深度嵌套游标的代码。审查这类代码的逻辑，看是否能用SQL语句来代替。
1.3 查找式查询
查找式查询（lookupquery）一般用于填充某些变量或执行数据的合法验证。但在循环中执行查找式查询会导致性能问题。
在代码清单1-5中，高亮显示的部分就是使用查找式查询来得到country_name值。程序对游标c1中的每一行都要执行一个查询来取得country_name的值。当从游标c1中取得的行数增加时，执行查找式查询的次数也增加了，这导致代码的效率低下。
代码清单1-5 查找式查询，对代码清单1-1的副本的修改
代码清单1-5的代码是过分简化的，对country_name的查找式查询实际上可以重写为主游标c1本身中的一个连接。第一步，应将查找式查询修改为连接，可是在实际的应用程序中，并不一定可以实现这种改写。
如果无法利用改写代码来减少查找式查询的执行次数，那么还有另一个选择。你可以定义一个关联数组来缓存查找式查询的结果，以便在随后的执行中重用这个数组，这样也能有效地减少查找式查询的执行。
代码清单1-6演示了数组缓存技术。不必再在游标c1返回的每一行中执行查询来得到country_name，而是用一个名为l_country_names的关联数组来存储本例中的country_id和country_name键—值对。关联数组和索引类似，任意给定的值都可以通过一个键值来访问。
在执行查找式查询前，通过EXISTS操作对一个数组中是否存在一个匹配country_id键值的元素做一个存在性验证，如果数组中存在这么一个元素，那么country_name就从数组中获取而不需要执行查找式查询。如果没有这样的元素，那么就执行查找式查询，并且把查到的结果作为一个新元素存入数组。
你还需要理解，这种技术非常适用于不同的键值很少的语句，在本例中，当country_id列的唯一值个数越少时，查找式查询的执行次数可能也越少。如使用示例模式，执行查找式查询的次数最多是23，因为country_id列只有23个不同的值。
代码清单1-6 用关联数组实现的查找式查询
注意 关联数组所需内存是在数据库服务器中专用服务器进程的PGA（Program GlobalArea，程序全局区）中分配的，如果数千个连接都要把程序的中间结果缓存到数组中，那么内存的占用将会大幅增加。你应当掌握每个进程的内存使用增加情况，并设计数据库服务器以适应内存的增长。
利用基于数组的技术也可在其他场景中消除不必要的工作。例如，可以通过把函数结果值存入关联数组来减少执行代价高昂的函数调用。1.5节讨论了减少执行次数的另一种技术。
注意 将函数结果存入一个关联数组仅适用于确定性函数。也就是说，这种函数对给定的输入集合，总是返回相同的输出。
1.4 对DUAL的过度访问
PL/SQL代码中对DUAL表的过度访问情况并不罕见。应当避免对DUAL表的过度访问。因为从PL/SQL中访问DUAL表会导致上下文切换，而这会损害性能。这一节总结了一些PL/SQL程序中过度访问DUAL表的常见原因，并讨论了减少这种访问的方案。
1.4.1 日期的算术运算
在PL/SQL中，没有理由通过访问DUAL表来执行算术运算或日期运算。因为大部分操作都能用PL/SQL语言本身的结构完成。甚至SYSDATE也能脱离开SQL引擎直接用PL/SQL访问。在代码清单1-7中加粗的SQL语句用于计算Unix新纪元时间（从1970年1月1日午夜到当前时间经历的秒数），使用了SELECT…fromDUAL语法。虽然访问DUAL表很快，但执行这个语句仍然会导致SQL和PL/SQL引擎之间的上下文切换。
代码清单1-7 过度访问DUAL——算术运算
可以使用如下的PL/SQL结构执行算术运算来避免对DUAL表的不必要访问。
完全不必调用SQL执行算术运算，简单地让PL/SQL做这项工作，代码会更易读，也更高效。
过度访问当前日期或时间戳是增加DUAL表访问的另一个原因。考虑在一个SQL语句中直接调用SYSDATE而不是先用SELECT语句将SYSDATE保存到一个变量，然后再把这个变量传递给SQL引擎。如果需要访问刚刚插入的列值，那么用returning子句来取出该列值就能实现。如果你需要在PL/SQL本身中访问SYSDATE，只需要用PL/SQL结构将当前日期取出并赋给一个变量即可。
1.4.2 访问序列
对DUAL表进行不必要的访问的另一种原因，是要从一个序列中获得下一个值。代码清单1-8显示的代码片段通过访问DUAL表从cust_id_seq序列中取出下一个值，并赋给一个变量，然后把这个变量的值插入customers表 。
代码清单1-8 过度访问DUAL——序列
更好的方法是不要将序列的值取出并存入变量，而是直接在INSERT语句本身中获得序列的值。下面的代码片段演示了INSERT语句怎么将序列产生的值插入customers表。用这种编码方法，就避免了对DUAL表的访问，因此也避免了引擎之间的上下文切换。
这个问题还有更好的解决办法：将整个PL/SQL块改写为一个SQL语句。改写后的语句0.2秒就执行完了，而基于PL/SQL循环处理的运行时间需要1.89秒。如下所示：
1.4.3 填充主—从行
另一个过度访问DUAL表的原因，是要把数据插入具有主从关系的几个表中。这种编码方法的典型例子是从序列中得到主表的主键值并赋给一个局部变量，再把这个局部变量插入主表和从表。这样做的原因是需要把主表的主键插入从表。
Oracle DataBase9i引入了一项SQL新功能，它允许从插入的行中返回插入值，从而为这类问题提供了更好的解决方案。你可以用DMLRETURNING子句取得新插入主表行的键值，然后就能将这些键值插入从表。例如：
1.5 过多的函数调用
认识到一个设计良好的应用程序会用到函数、过程和包很重要。但本节不是讨论应该怎么使用模块化的方法编程，而是讨论在编程中如何避免不必要的函数调用。
1.5.1 不必要的函数调用
函数调用通常意味着将指令集的不同部分要装载到CPU。执行时需要从指令的一个部分跳转到另一个部分。这种跳转执行增加了性能问题，因为这引起了指令管道的大量转储（dump）和重新填充，结果是加重了CPU的负担。
通过避免不必要的函数执行，可以避免不必要的指令管道刷新和重新填充，这样就使得对CPU的需求降到最低。再次声明，我并不反对模块化编程，而只反对过度和不必要的函数调用。最好用例子来解释。
在代码清单1-9中，log_entry是一个调试函数，在每次合法性验证中都会调用它。但这个函数本身有一个对v_debug的检查，并且只有在调试标记设为“真”时才将消息插入。假设有个程序的循环中包括执行数百个这样复杂的业务合法值验证，那么实际上，即使v_debug标志的值设为“假”，log_entry函数也会被不必要地调用数百万次。
代码清单1-9 不必要的函数调用
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.54
代码清单1-9中的代码可以改写为仅当标志变量l_debug设为“真”时才调用log_entry函数。这个改写减少了不必要的log_entry函数执行。改写后的程序在0.43秒内执行完成。如果执行次数更多，那么性能的提高会更明显。
如果还嫌不够好，可以考虑用条件编译结构来完全避免代码片段的执行。在代码清单1-10中，加粗的代码使用$IF-$THEN结构和条件变量$debug_on。如果条件变量$debug_on是“真”，那么代码块得到执行。在一个生产环境中，变量$debug_on会设为“假”，这就消除了函数执行。注意，程序的执行时间进一步减少到了0.34秒。
代码清单1-10 用条件编译来避免不必要的函数调用
不必要的函数调用问题通常在从一个模板程序复制再修改的程序中频繁出现。观察程序，如果没必要调用某个函数，就不要调用它。
解释和本地编译的对比
PL/SQL代码默认是解释执行的。在编译PL/SQL的过程中，代码被转化为一种中间格式并存储在数据字典中。在执行时，引擎执行中间代码。
Oracle Database9i引入了一项新功能：本地编译，即把PL/SQL代码编译成机器指令并作为共享库存储。过度函数调用对本地编译的影响可能更小，因为现代编译器能够将子程序展开而避免指令的跳转。
1.5.2 代价高昂的函数调用
如果某个函数需要几秒的运行时间，那么在循环中调用此函数将导致代码的性能低劣。你应当优化频繁执行的函数以使它尽可能有效率地运行。
在代码清单1-11中，如果函数calculate_epoch在一个循环中被调用数百万次。即使每次执行此函数只耗费0.01秒，一百万次执行此函数也要耗费2.7小时。解决这个性能问题的办法之一是优化此函数使它执行一次只要几毫秒，不过这种深度的优化很难做到。
代码清单1-11 代价高昂的函数调用
另一个可选方案是把函数执行的结果预存起来，这样就避免了在查询语句中执行函数。可以用一个基于函数的索引做到这一点。代码清单1-12创建了一个基于calculate_epoch函数的索引。SQL语句的性能从1.39秒提高到了0.06秒。
代码清单1-12 用基于函数的索引代替执行代价高昂的函数调用
你应该明白基于函数的索引也是有代价的。INSERT语句和更新time_id列的UPDATE语句会导致调用函数和维护索引的开销。需要认真地权衡DML操作中的函数执行开销和SELECT语句中的函数执行开销，并选择一个开销较低的方法。
注意 从OracleDatabase11g开始，可以创建一个虚拟列，然后再在虚拟列上创建一个索引。虚拟列上索引的影响和基于函数的索引的影响是一样的。虚拟列优于基于函数的索引的优点是，你可以基于虚拟列对一个表进行分区，而这是基于函数的索引所做不到的。
另一种方法是利用从OracleDatabase11g开始提供的result_cache来优化代价高昂的函数调用。这种功能会将函数调用的结果记忆在一个实例的SGA所分配的结果缓存中。重复用同样的参数执行函数会从结果缓存中取值，而不需要重复执行函数。代码清单1-13显示的是利用函数result_cache功能来提高性能的例子。执行同样的SQL语句用了0.81秒。
代码清单1-13 带结果缓存的函数
总之，过度的函数执行导致性能问题。如果无法减少或消除函数执行，那么可以利用基于函数的索引或result_cache作为暂时的解决办法，从而将函数调用带来的影响降到最低。
1.6 数据库链接调用
过度使用数据库链接调用会影响应用程序的性能。在一个循环中通过数据库链接来访问远程表或修改远程表是一个不可扩展的方法。因为对远程表的每一次访问，都会导致本地数据库和数据库链接中包含的远程数据库之间的多个SQL*Net包的交换。如果数据库在地理上处于不同的数据中心，或者更糟糕一些，数据库是跨国的，那么等待SQL*Net的流量就会导致程序的性能问题。
在代码清单1-14中，游标每返回一行，远程数据库上的customer表都要被访问一次。我们假定一次网络往返需要0.1秒，那么100万次往返调用将需要大约27小时才能完成。而位于国内不同地区的数据库之间的响应时间为0.1秒是很常见的。
代码清单1-14 过度使用数据库链接调用
慎重地使用实体化视图能减少程序执行中的网络往返。在代码清单1-14的案例中，可以为远程customer表创建一个本地实体化视图。在程序执行前先刷新实体化视图，然后在程序中访问实体化视图，将表在本地实体化减少了SQL*Net往返调用次数。当然，作为应用程序的设计者，你需要比较实体化整个表和在循环中访问远程表的代价，选择最理想的解决方案。
另一种选择是将程序改写为使用远程表连接的SQL语句。Oracle数据库的查询优化器能优化这种语句，以减少SQL*Net往返的开销，而要使用这种技术，就需要重写程序，使这个SQL语句只执行一次，而不是循环执行。
调优代码清单1-14中程序的首选步骤是将数据实体化到本地或将代码改写为包含远程连接的SQL语句。不过，如果你无法做到这些，还有另外的解决办法。作为一个临时措施，你可以将程序转化为能够使用多进程架构。例如进程1处理1～100000范围内的客户，进程2处理100 001～200000之间的客户，等等。把这种逻辑应用到示例程序，创建10个并行执行进程，你就可以将程序的总运行时间减少到大约2.7小时。另一种可采取的方法是使用DBMS_PARALLEL_EXECUTE，将代码分解成多个任务并行处理。
1.7 过度使用触发器
尽管也能用Java语言来写触发器代码，但触发器通常还是用PL/SQL编写。由于性能的原因，过度使用触发器是不理想的。数据库表中行的变化在SQL引擎中执行而触发器是在PL/SQL引擎中执行，如果触发器频繁触发，程序就会遭遇到十分严重的上下文切换问题。
在一些情况下，触发器是无法避免的。例如，复杂业务中的合法性验证就不可避免要用到触发器。在这些情况下，你应当在合法性验证很复杂时才用PL/SQL编写，而要避免滥用触发器进行简单的合法性验证。例如，用check约束而不是用一个触发器来验证列的值是否在合法值代码清单之内。
还有，应避免对一个触发事件使用多个触发器。不要为一个事件编写两个触发器，而应当把它们合并为一个，以使上下文切换的次数最小化。
1.8 过度提交
在PL/SQL程序循环中经常见到插入、修改或删除每行后面紧接着就是提交。这种在每行后面提交的编码方法会导致程序执行得更慢。频繁的提交产生更多的重做（redo），需要日志写入器更频繁地将日志缓冲区的内容保存到日志文件。过度提交还会导致数据一致性问题，并且消耗更多的资源。虽然Oracle已经优化了PL/SQL引擎以减少频繁提交的影响，但这无法替代由于自身编写良好从而减少了提交的代码。
你应当只在一项业务交易完成后提交，如果在到达业务交易的边界前就提交了，就会遇到数据一致性问题。如果必须用提交来提升中断后可重新开始的能力，那么建议使用批量提交。比起每行之后提交，每1000或5000行批量提交一次更好。每批的数量选择取决于应用程序。更少的提交会使程序的运行时间缩短。而且，从应用程序发出更少的提交也能提高数据库的性能。
1.9 过度解析
不要在PL/SQL循环中使用动态SQL语句，因为这么做会引起过度解析问题。反之，应通过使用绑定变量来减少硬解析的次数。
在代码清单1-15中，从游标c1取得cust_id，然后根据cust_id访问customers表，来获取客户的详细信息。构造出一个包含字面值的SQL语句，然后用本地动态SQL的EXECUTEIMMEDIATE结构来执行。问题在于每从游标c1取出一个不重复的cust_id值，就会构造一个新的SQL语句，然后将它发送到SQL引擎去执行。
执行共享池中不存在的SQL语句，就会触发一次硬解析。过度硬解析会对库缓存（librarycache）产生压力，因而降低了应用程序的可扩展性和并发执行能力。当游标c1返回的行数增加时，硬解析的次数会线性增长。这个程序也许可以在只有少量行需要处理的开发数据库中正常运行，但用这个方法在生产环境运行就会很成问题。
代码清单1-15 过度解析
应当尽可能减少硬解析。在循环中执行动态SQL将增加硬解析的影响，如果并发执行增多，这种影响就会放大。
1.10 小结
本章介绍了多个不适合使用PL/SQL的场景。请牢记，SQL是一种集合语言，而PL/SQL是过程性语言。在设计程序时，可以考虑下列建议。
用SQL解决查询问题。用集合的方式进行思考，用SQL写的查询，比起用嵌套循环逐行处理的方式执行查询的PL/SQL程序更加易于调优。
如果必须用PL/SQL来编写代码，请尝试尽可能将较多的工作负担交给SQL引擎。这种技术随着Exadata等新技术的出现而变得更重要。Exadata数据库机中的智能扫描设备能将工作负担交给存储节点，从而提高用SQL编写的程序性能。而PL/SQL结构不能从Exadata数据库机获得同样的好处，至少在11gR2中是不能的。
如果必须使用循环，那么使用PL/SQL提供的批量处理功能。利用本章介绍的技术减少在PL/SQL中的不必要工作，比如不必要的函数执行或者对DUAL表的过度访问。
只把使用单行、基于循环的处理作为最后的手段。
没错，用PL/SQL处理所有的数据和业务，用Java或其他语言来展现界面和进行用户合法性验证。利用本章描述的方法可以编写出高度可扩展的PL/SQL语言程序。
Oracle PL/SQL实战 pdf下载声明
本pdf资料下载仅供个人学习和研究使用，不能用于商业用途，请在下载后24小时内删除。如果喜欢，请购买正版
