配置路线图
因为不存在类似神奇配置这样的事情，我们需要一个可靠的、可信的规程来帮助我们。图9-1总结了我所使用的主要步骤。它们的描述如下所示。
(1)有两个初始化参数需要不断调整：ptimizer_mode和db_file_multiblock_read_count。稍后你会看到，后者并不总是与查询优化器本身直接相关。然而，某些操作的性能可能会极大地依赖于它。
(2)因为这一步中调整的初始化参数的默认值通常来说工作良好，所以这一步是可选的。不管怎样，这一步的目标是启用或禁用查询优化器的专项特性。
(3)因为系统统计信息和对象统计信息为查询优化器提供至关重要的信息，所以必须要收集它们。
(4)通过设置workarea_size_policy初始化参数，可以选择手工还是自动调整在内存中存储数据操作的工作区大小。根据不同的选择方法，其他的初始化参数可以在第5步或第6步中进行设置。
(5)如果调整工作区大小是自动的，则设置pga_aggregate_target初始化参数。另外，从12.1版本开始，同时还可以修改pga_aggregate_limit初始化参数。
(6)如果调整工作区大小是手动的，实际大小取决于使用内存的操作的类型。基本上，每种类型的操作都有一个具体的参数。
(7)当第一部分的配置就位时，就该测试应用程序了。在测试过程中，没有提供需求性能的组件的执行计划被收集起来。通过分析这些执行计划，你应该能够推断出问题所在。注意在这一阶段，重点是识别出普遍行为，而非个例行为。举例来说，你可能注意到查询优化器使用过多或过少的索引或者没有正确识别限制条件。
(8)如果查询优化器能够为大部分SQL语句生成高效率的执行计划，那表明配置良好。如果不能，继续进行步骤9。
(9)如果查询优化器趋向于使用过多或者过少的索引或嵌套循环，通常可以通过调整初始化参数optimizer_index_caching和optimizer_index_cost_adj来修复这个问题。如果查询优化器在估算基数方面出现重大错误，可能是因为一些直方图缺失或者需要调整。调整动态采样也可能会有帮助。从11.1版本开始，扩展的统计信息也可能有所帮助。
根据图9-1,步骤1-6中设置的初始化参数不能在事后进行修改。当然了，这也不是一成不变的。如果你无法通过调整与索引相关的初始化参数或步骤9中的直方图来获得理想的结果，可能有必要从头来过。还有必要提一下，因为有几个初始化参数对系统统计信息有影响，在更改完它们之后，可能有必要重新计算系统统计信息。
设置正确的参数
显然Oracle并不只是随机提供新的初始化参数。相反，引入的每个初始化参数都是为了控制查询优化器的某一特性或者行为。尽管有重复的嫌疑，我还是要提醒你Oracle对于新参数的引进意味着没有一个单独的值能够适用于所用情况。因此，对于每一个初始化参数，必须通过应用程序负载情况和数据库引擎运行的系统共同推断出一个合理的取值。
要为查询优化器执行一个成功的配置，重要的是要理解它是如何运作的，以及每个初始化参数对它的影响。有了这个认识，就不要随意对配置作调整，也不要从最近在网上找到的文章中复制“理想的值",而应该从以下方面着手。
Ø 充分了解现状。举例来讲，为什么查询优化器选择了一个非最优的执行计划?
Ø 决定要实现的目标。换句话说，你要获得什么样的执行计划?
Ø 找出有哪些初始化参数或者统计信息应该进行调整以达到你设置的目标。当然，在某些情况下仅仅设置初始化参数是不够的。可能有必要修改SQL语句或者数据库设计。
参数可分成两组：一组参数只影响查询优化器的操作，另一组则与程序全局区(PGA)有关。
