SQL处理是SQL语句的解析,优化,行源生成和执行。
下图描述了SQL处理的一般阶段。根据声明,数据库可能会省略其中一些阶段。
图3-1 SQL处理阶段
本节包含以下主题:
父主题: SQL处理
3.1.1 SQL解析
SQL处理的第一阶段是解析。
解析阶段涉及将SQL语句的各个部分分成其他例程可以处理的数据结构。数据库在应用程序指示时解析一条语句,这意味着只有应用程序(而不是数据库本身)才能减少解析次数。
当应用程序发出SQL语句时,该应用程序将对数据库进行解析调用,以准备执行该语句。解析调用将打开或创建一个游标,该游标是特定于会话的专用SQL区域的句柄,该区域包含已解析的SQL语句和其他处理信息。游标和专用SQL区域位于程序全局区域(PGA)中。
在parse调用期间,数据库执行检查,以识别在执行语句之前可以发现的错误。某些错误无法通过解析捕获。例如,仅在语句执行期间,数据库才能在数据转换中遇到死锁或错误。
本节包含以下主题:
也可以看看:
父主题: 关于SQL处理
3.1.1.1语法检查
Oracle数据库必须检查每个SQL语句的语法有效性。
如果一条语句违反了格式正确的SQL语法的规则,则该检查将失败。例如,以下语句失败,因为关键字FROM
的拼写错误为FORM
:
SQL> SELECT * FORM employees;
SELECT * FORM employees
*
ERROR at line 1:
ORA-00923: FROM keyword not found where expected
父主题: SQL解析
3.1.1.2语义检查
语句的语义是其含义。语义检查确定语句是否有意义,例如,语句中的对象和列是否存在。
语法正确的语句可能无法通过语义检查,如以下不存在的表的查询示例所示:
SQL> SELECT * FROM nonexistent_table;
SELECT * FROM nonexistent_table
*
ERROR at line 1:
ORA-00942: table or view does not exist
父主题: SQL解析
3.1.1.3共享池检查
在解析期间,数据库执行共享池检查,以确定它是否可以跳过资源密集型语句处理步骤。
为此,数据库使用哈希算法为每个SQL语句生成哈希值。声明哈希值是SQL ID所示V$SQL.SQL_ID
。此哈希值在Oracle数据库的版本中是确定性的,因此单个实例或不同实例中的同一语句具有相同的SQL ID。
用户提交SQL语句时,数据库将搜索共享的SQL区域,以查看现有的已解析语句是否具有相同的哈希值。SQL语句的哈希值不同于以下值:
- 语句的内存地址
Oracle数据库使用SQL ID在查询表中执行键控读取。这样,数据库即可获取该语句的可能内存地址。
- 语句 执行计划的哈希值
一个SQL语句在共享池中可以有多个计划。通常,每个计划都有不同的哈希值。如果相同的SQL ID具有多个计划哈希值,则数据库知道该SQL ID存在多个计划。
解析操作分为以下几类,具体取决于提交的语句的类型和哈希检查的结果:
- 硬解析
如果Oracle数据库无法重用现有代码,则它必须构建该应用程序代码的新的可执行版本。此操作称为硬解析或库高速缓存未命中。
注意:
数据库始终执行DDL的硬解析。
在硬解析期间,数据库多次访问库高速缓存和数据字典高速缓存以检查数据字典。当数据库访问这些区域时,它将在所需对象上使用称为锁存器的序列化设备,以使它们的定义不变。锁存争用会增加语句执行时间并减少并发性。
- 软解析
一个软分析是任何解析这不是一个硬解析。如果提交的语句与共享池中的可重用SQL语句相同,则Oracle数据库将重用现有代码。代码的这种重用也称为库缓存命中。
软解析在执行多少工作方面可能有所不同。例如,配置会话共享SQL区域有时可以减少软解析中的锁存量,从而使它们“更软”。
通常,软解析优于硬解析,因为数据库会跳过优化和行源生成步骤,直接执行。
下图是UPDATE
专用服务器体系结构中语句的共享池检查的简化表示。
图3-2共享池检查
如果检查确定共享池中的语句具有相同的哈希值,则数据库将执行语义和环境检查以确定该语句是否具有相同的含义。相同的语法是不够的。例如,假设有两个不同的用户登录数据库并发出以下SQL语句:
CREATE TABLE my_table ( some_col INTEGER );
SELECT * FROM my_table;
SELECT
两个用户的语句在语法上是相同的,但命名了两个单独的模式对象my_table
。这种语义上的差异意味着第二条语句不能为第一条语句重用代码。
即使两个语句在语义上是相同的,环境差异也可能导致硬解析。在这种情况下,优化器环境是可能影响执行计划生成的所有会话设置,例如工作区大小或优化器设置(例如,优化器模式)。考虑由单个用户执行的以下一系列SQL语句:
ALTER SESSION SET OPTIMIZER_MODE=ALL_ROWS;
ALTER SYSTEM FLUSH SHARED_POOL; # optimizer environment 1
SELECT * FROM sh.sales;
ALTER SESSION SET OPTIMIZER_MODE=FIRST_ROWS; # optimizer environment 2
SELECT * FROM sh.sales;
ALTER SESSION SET SQL_TRACE=true; # optimizer environment 3
SELECT * FROM sh.sales;
在前面的示例中,相同的SELECT
语句在三个不同的优化器的环境中执行。因此,数据库为这些语句创建三个单独的共享SQL区域,并强制对每个语句进行硬解析。
也可以看看:
- Oracle Database Concepts了解私有SQL区域和共享SQL区域
- 《 Oracle数据库性能调优指南》以了解如何配置共享池
- Oracle Database Concepts了解锁存器