2.6 流程、资源和组件优化方法论
流程、资源和组件优化方法论是本书几位作者综合多年性能优化方法论实践提出的最新的Oracle业务系统性能优化方法论。流程、资源和组件优化方法论以流程响应分析为核心，辅助以流程处理的组件和涉及的资源分析，发现导致性能问题的根本原因，并采取适当的手段进行性能改善。本书从流程、资源和组件优化方法论出发，全面构建性能优化的可测量体系，并通过大量的性能优化实践案例来验证方法论的有效性。
2.6.1 吞吐量和响应时间关系曲线
吞吐量和响应时间关系曲线是流程、资源和组件优化方法论的核心理论基础。吞吐量和响应时间关系曲线强调响应时间输出是在特定输入吞吐量之后作用的结果，输入吞吐量是先导因素或者本质。输出响应时间是滞后的响应时间，是输入吞吐量加载下的自然反应。无论是流程、资源还是组件，都遵循吞吐量和响应时间关系曲线。
2.6.2 流程和流程响应分析
基本上，可以把所有的业务都表述为流程，业务系统性能优化本质上是一个流程改善的过程。任何流程改善的目标或者是提高效率或者是降低成本，其中，提高效率和降低成本在大多数情况下趋于一致，只是流程改善的目的不同。任何业务系统的性能衡量都表述为以下两点。
在可接受响应时间范围内提高吞吐量。
缩短响应时间或者加快响应。
任意的流程必然包含输入压力和输出响应，业务系统的性能衡量指标实际上就是表述为流程的输入压力和输出响应，是流程的自然描述。或者说，从流程角度出发看待性能问题就是性能优化分析的自顶向下的分析方法。
我们把业务在Oracle数据库的处理过程视同流程，性能优化的过程就是一个流程优化和改善的过程。在任何时候，流程分解分析和时间响应分析都是流程优化和改善的基本工作方法。下面对流程、流程分解、流程优化和流程影响进行简要描述。
流程：为了完成一定的目标，按照时间次序处理的过程。流程包含输入项和输出项。
流程分解：每个流程都是一系列的子流程，通过流程分解可以把流程逐步细化，直至不可分解为止。流程分解可以帮助我们发现流程响应的问题主要发生在哪个子流程上，从而使我们把焦点聚焦在对应的子流程上。
流程优化：通过时间响应分析发现流程的问题，通过流程分解进行精细定位，通过涉及的资源和组件影响分析、改善流程使之更有效率或者成本更低。
流程影响：流程和流程之间存在相互影响的因素，其效率并不是线性增长，而是存在一个影响因子。
显然，满足时间顺序执行和具有匹配效率的流程才可能具有良好的性能，业务流程的整体响应能力是由响应能力最弱的子流程决定的。
Oracle数据库业务主要分为以下三大流程。
数据库登录流程：客户端通过数据库账户登录数据库的过程，表述为数据库登录流程。
数据库业务处理流程：客户端发起SQL执行申请，通过一系列处理并返回处理结果给客户端的过程，表述为数据库业务处理流程。SQL处理流程是数据库业务流程的基本构成单元，数据库业务处理流程是SQL处理流程的时间序列构成。
混合流程：流程处理中包含数据库登录流程和数据库业务处理流程，主要作用在Database Link环境中，其他需要通过连接数据库来达成一次业务响应的业务流程也表述为混合流程。由于混合流程只是两个不同流程的时间次序叠加，所以我们不对混合流程进行独立的描述和处理。
1.?数据库登录流程
数据库登录流程一般包含以下处理过程。
Step 1：Client发起登录握手。
Step 2：握手指令以及相关信息传输。
Step 3：listener验证阶段。
Step 4：服务进程和session派生阶段。
Step 5：用户验证和权限生成阶段。
Step 6：session审计阶段。
Step 7：登录触发器阶段。
Step 8：响应客户端返回阶段。
为了简化处理，我们把数据库登录流程缩减为以下处理过程。
Step 1：客户端登录请求。
Step 2：listener处理和响应。
Step 3：服务进程派生和session生成。
Step 4：用户验证和权限判断。
Step 5：session审计。
Step 6：登录触发器。
Step 7：响应客户端。
为了衡量数据库登录流程，需要了解在大流程和子流程之上的输入吞吐量压力指标和输出响应时间指标，后面第3章将会构建数据库登录流程涉及的可检测性能指标。
2.?数据库业务处理流程
数据库业务处理流程的基础单元为SQL处理流程，SQL处理流程符合大多数形态的流程形式，包含业务申请、计划分析和指定、计划执行和响应。具体包含以下过程。
Step 1：客户端发起语句执行申请。
Step 2：指令传输。
Step 3：应用服务器处理阶段。
Step 4：指令传输到数据库。
Step 5：分析指令并生成执行计划。
Step 6：执行生成的执行计划。
Step 7：一次或者多次响应结果传给应用服务器。
Step 8：应用服务器返回响应给客户端。
commit或者rollback作为特殊的SQL语句，我们把它作为SQL处理中的一个特殊阶段，表述为提交阶段。
数据库业务处理流程就是SQL语句执行流程的时间序列，由一条或者多条SQL语句构成。
3.?流程分析的基本工作方法：UOWTBA
UOWTBA优化方法是流程性能分析的基本工作方法，通过对流程以及子流程的吞吐量和响应时间分析，确认性能问题是发生在子流程还是发生在全局流程中。基本工作方法如下。
Step 1：判断出现性能变异的流程。
Step 2：使用UOWTBA方法分析每个流程和子流程的输入吞吐量和输出响应时间。
Step 3：判断是输入吞吐量变异还是输出响应时间变异或者两者都变异。
Step 4：发现出现问题的是流程还是子流程。
Step 5：如果输入吞吐量变异，则考虑降低输入压力吞吐量。
Step 6：如果输出响应时间变异，则进一步分解服务时间和等待时间。
Step 7：综合判断导致输出响应时间增加的可能因素，大部分是资源问题。
2.6.3 资源分析
任何流程的执行和响应都需要资源的参与，没有资源就不会有流程的执行和响应。为了使资源分析更有价值，我们把资源从传统的操作系统资源进行扩充，把数据库资源也纳入资源管理范畴。从Oracle业务系统性能优化的角度出发，主要关心以下不同的资源。
1.?操作系统硬件资源
（1）CPU
数据库系统任何业务的运行都需要CPU的参与。CPU是计算机系统中唯一一个主动式运行组件。CPU资源的不足会影响到全局性业务的运行。
（2）内存和虚拟内存
Oracle实际上使用的是虚拟内存，虽然其只有在物理内存中运行才有可能性能良好。Oracle的所有操作都运行在内存中，内存的不足或者虚拟内存性能的下降也会极大程度地影响Oracle业务系统的运行。
（3）磁盘
Oracle数据库就是一堆存储在磁盘系统上的文件，Oracle软件就是读取、更新和保存这些存储在磁盘上的数据。从Oracle可执行程序到最终读取文件中的数据，Oracle要经过漫长的流程（以SAN存储为例）：逻辑卷、文件系统缓存、HBA、SAN交换机、存储系统Disk Control、存储系统缓存、存储系统磁盘。I/O子系统作为Oracle业务系统漫长而缓慢的链路，在相当多的场合下成为Oracle业务系统的问题所在。
（4）网络
网络系统是比I/O子系统效率更低的资源供给者，如何缩减网络往返数量是一个业务系统需要考虑的问题。当需要大规模的数据在网络上往返的时候，网络几乎会成为问题
所在。
2.?数据库资源或者并发性资源
绝对的硬件资源供给并不能达到很好的性能，并发性资源是OLTP业务系统高吞吐量响应的绝对因素所在。主要的并发性资源包含lock、buffer lock、latch和mutex等。
（1）lock
当Oracle数据库需要访问实际的数据库资源的时候，比如表格的数据、表空间、数据文件、sequence等各种不同对象，为了保持一致性，需要获得锁的保护，避免出现不一致性。
（2）buffer lock
当Oracle在内存中访问数据块的时候，为了保持一致性，当涉及块数据变更的时候，需要获得buffer lock的保护。
（3）latch
Oracle为了加速业务处理，在内存中加载大量的结构性对象，所有这些结构性对象的访问都需要latch的保护，以保持内存结构的一致性。
（4）mutex
mutex是latch的CAS实现，或者说是一种轻量级latch，具有比latch更细的粒度，所以具有更好的并发性支持功能。需要注意的是，并不是说mutex比latch具有更好的获得和释放效率而使用mutex，而是mutex比latch具有更低的粒度、更低的内存消耗成本而使用mutex。Oracle是为了更好的并发性响应而使用mutex，而不是为了更加快速的响应。
（5）其他杂项资源
比如process、session等这类资源的缺乏最终会表现为lock和latch的冲突，所以，除了资源不足报错之外，并没有太大价值去研究这些资源。
3.?资源和吞吐量/响应时间曲线
无论是硬件资源还是并发性资源，都遵循吞吐量/响应时间曲线，资源的分析可以完全围绕着吞吐量/响应时间曲线来进行。
2.6.4 组件
流程的执行不是空中楼阁，需要通过一个个处理节点或者处理中心完成，对于这些处理节点或者处理中心，我们将其表述为组件。任何一个处理节点或者组件出现故障或者出现处理效率问题，都有可能影响业务流程的性能。
Oracle数据库系统主要由各种组件构成，如lisgtener、buffer cache、shared pool等，不同的业务系统流程可能会通过不同的组件执行和处理。具体的组件列表和分析在组件章节中展开描述。
业务流程或者子流程总是通过一个个处理节点或者组件提供服务，资源就是为这些服务提供能力上的保障。按次序执行的组件或者处理中心必须具有匹配的输入和输出，才有可能使业务流程高效运转。
绝大部分的Oracle数据库组件都遵循吞吐量和响应时间曲线，在一个业务处理流程中，组件的输出流会成为下一个处理组件的输入流，只有后续处理节点的处理能力等于或者大于前面处理节点的能力，才可能使业务流程毫无阻碍地运转和响应。