Oracle性能优化之游标及SQL

我们要先说一下游标这个概念。

从 Oracle 数据库管理员的角度上说，游标是对存储在库缓存中的可执行对象的统称。SQL 语句是存储在库缓存中的，它是游标。除了它之外，还有 Oracle 的存储过程也是存储在库缓存中的可执行对象，从 Oracle DBA 的角度上说，它也是游标。Oracle 也把它算为游标，在某些和游标相关的视图中，也会显示存储过程的一些信息的。但从开发者的角度说，只有 SQL 语句才是游标。

你的应用程序或许是用 Java、Pro*C 等语言开发的，也可能有中件间，等等，对于 DBA 来说，我们不必过多的关心这些。以一个常见的三层应用为例， 如下图：

类似的图我们在很多地方都可以看到，假设这是一个三层 J2EE 应用。客户端调用的 Java 应用程序存放在中间的应用服务器层，应用程序的执行由应用服务器负责。

如上图这段 Java 应用程序，它的执行就是应用应用服务器的任务。但是，当执行到 executeQuery ("select * from Test") 语句时，这条 Java 语句要求从数据库服务器中查询表 Test。发下图：

这条语句的执行，是由数据库服务器负责的。数据库服务器只负责以最快的速度将 “Select * from test” 执行完毕。其他的它一概不负责。我们作为 DBA，只要保证 SQL 语句可以更快的执行就行了，至于应用程序逻辑方面的问题，不由我们负责。也就是说，作为 DBA，我们不必负责具体代码的问题，我们只负责 SQL 语句的执行。每条送交 Oracle 执行的 SQL 语句，无论这条语句是你手动在 SQL*Plus 命令窗口中敲入的，还是应用服务器传送给 Oracle 要求执行的，它们都以一样的方式被传递到 Oracle 中，由服务器进程执行。这些 SQL 语句的执行情况、具体的执行计划等数据资料会在一些视图中被记录下来，以供 DBA 追踪问题、调优 SQL 的执行。

下面，我们就介绍一下这些相关 SQL 执行情况的视图。我们再强调一个名词，对于从任何地方传递给 Oracle 数据库服务器要求执行的东西，我们都称为游标。它主要包括 SQL 语句和 PL/SQL 程序段。

SHARABLE_MEM：游标所占共享内存

SORTS：游标完成的排序次数

FETCHES：抓取的次数

EXECUTIONS：执行次数

LOADS：游标被加载或重新加载到库缓存中的次数。游标只所以被重新加载有可能是游标无效或库缓存内存不足。

INVALIDATIONS：游标的无效次数

PARSE_CALLS：游标的解析次数，包括硬解析与软解析

DISK_READS：游标执行了多少次物理读

BUFFER_GETS：逻辑读的次数

USER_IO_WAIT_TIME：用户 I/O 等待时间

PARSING_SCHEMA_NAME：最先解析此游标的方案 ID

CPU_TIME：游标解析、执行、抓取时所用的 CPU 时间。单位是微秒。

ELAPSED_TIME：游标解析、执行、抓取时所用的总时间。单位是微秒。

这个视图中 DISK_READS、BUFFER_GETS、CPU_TIME、ELAPSED_TIME 这四个列在调优 SQL 语句时最为重要。在数据库系统的速度不是太另人满意时，如果你已经确定过了，不是其他方面的原因，而是 SQL 语句性能的问题，只是无法确定是那条、或那些条语句拖慢了整体的速度。那么此时选择调优物理读、逻辑读最多的，或最耗 CPU 时间的 SQL 语句进行调节，往往可以取得今人满意的性能增长。

我们也可以以 EXECUTIONS（执行次数）最多的 SQL 语句为调优对象。另外，PARSE_CALLS 是解析次数，对于此列值最多的 SQL 语句，我们可以看看是否可以降低语句的解析次数。

关于 SQL 调优，和程序的调优是一样的。如果我们从事过代码优化这样的工作，就会知道，对于一个大型的应用程序来说调优的方法也是要从执行次数最多的那部分代码、或从最消耗资源的代码入手。

还有一个问题，就是文档中关于这个视图会经常提到一个概念：子游标与父游标。如果两个游标的文本一模一样，但由于环境不同，比如，游标所操作的表是不同用户下的同名表，这两个游标是不能共享执行计划的。它们都有各自的执行计划存在库缓存中。这两个游标就是子游标，Oracle 还会建立一个父游标，父游标中没有执行计划，它只是文本相同但执行计划不同的所有游标的代表。

其实在库缓存中，即使没有文本相同的子游标，Oracle 会为每个游标都创建父游标。因为父游标是文本相同的子游标的代表吗，所有文本相同的游标共享同一个父游标。

也就是说，只要你执行 SQL 语句，Oracle 都会在库缓存中保存一父一子两个游标。如果你执行了文本相同但环境不同因而不能共享执行计划的 SQL 语句，那么一个父游标可能就对应多个子游标。

父游标没有执行计划，它只有一信息管理性数据，Oracle 添加它的目的就是为了管理文本相同的游标。有一个视图是专门针对父游标的，就是 V$sqlarea。下面我们说一下这个视图。

V$SQLAREA 和 V$SQL 的列几乎是一模一样的。在 V$SQLAREA 中汇总了子游标的数据。如果有两个语句：语句 A 和语句 B，它们文本一模一样，但是由于环境不同没有共享执行计划，而是有各自的执行计划。也就是语句 A 和语句 B 是同一父游标下的子游标。在 V$SQL 视图中，因为它是显示子游标的，所以语句 A 和语句 B 各占一行，假设语句 A 的 DISK_READS（物理读）是 100，语句 B 的物理读是 3000。V$SQLAREA 是显示父游标信息的，语句 A 和语句 B 因为文本相同，它们两个对应同一个父游标，在 V$SQLAREA 中占一行。在 V$SQLAREA 中，语句 A 和语句 B 父游标行中的 DISK_READS 就是 3100，也就是语句 A 和语句 B 的和。V$SQLAREA 中的其它列也是如此，都是 V$SQL 中相应子游标的合计。

有一个列是 V$SQL 中没有的，就是：VERSION_COUNT，它是对应同一父游标的子游标的数量。如果这个数字太高，可能代表由于某些原因使本可以共享执行计划的游标没有共享。

这个视图和参数涉及游标的打开。什么是游标的打开，就是在库缓存中，用户在软、硬解析游标时，会在游标对象的句柄上加一个锁，也就是 Library cache lock。在解析并执行完游标后，这个锁并不会马上去掉，而是会一直保留着，直到用户发出了 Close 命令关闭游标时为止。我们在 SQL*Plus 命令窗口中发出的命令，在抓取完所有行后，SQL*Plus 将自动为我们发出 Close 命令来关闭游标。

当游标打开时，Library cache lock 将一直保持，这样，即使库缓存内存紧张，需要老化对象，也不会老化这些还正在加锁的对象。因此，如果用户不停的要求数据库服务器打开游标、执行 SQL，但却忘了关闭游标，这很容易耗尽共享池的内存。为此，Oracle 准备了一个参数，就是 Open_cursor，它的默认值在 9i 下是 50，在 10g 中是 300，也就是说，在 10g 下，每个会话最多只能同时打开 300 个游标。有了这个限制，就不用害怕用户不停的打开游标但又不关闭它，而耗尽共享池内存了。

如果会话同时打开的游标数量超出了 Open_cursor 参数的限制，Oracle 将禁止会话打开新的游标。同时报出错误：ORA-01000: 超出打开游标的最大数 。

在用户断开会话的连接后，会话打开的这些游标将自动关闭。

V$open_cursor 视图专用来查看当前会话打开的游标信息。它只能查看当前会话打开的游标。

如果应用程序中有很多类似下面这样的 SQL 语句：

select * from 某表 where id=1;

select * from 某表 where id=2;

select * from 某表 where id=50;

等等，这些 SQL 语句严格来说是无法共享游标（也就是共享执行计划）的，但是这些语句所需要执行计划其实都是一样的。无论你在表中查询 ID 为 1 的行还是查询 ID 为 100 的行，执行方式应该是一样的。如果你想让这样的语句共享游标，那么，你可以改变 Cursor_sharing 参数的值。

此参有三个值：

• Ÿ EXACT：这个值是默认值。除非游标文本一模一样，否则不会共享游标。

• Ÿ SIMILAR：这个最智能，如果游标只有条件中的数据值部分不同，并且库缓存中原有游标的执行计划对于新执行的 SQL 语句也是最优的，将不再为 SQL 语句创建新的游标，而是让它共享库缓存中原有的游标。

• Ÿ FORCE ：不比较执行计划是否最优，只要游标中除了条件中的数据值部分不同外，其他部分都相同，就会共享游标。

此参数可以在会话级修改，也就是可以使用 Alter session 修改它的值，这将只影响某一个会话，而不会影响其他会话。