SQL-执行过程详解

SQL-执行过程详解

一、SQL语句执行原理：

第一步:客户端把语句发给服务器端执行

在客户端运行SQL指令时，该指令会被传输至服务器端，由服务器端的进程负责执行处理。换言之，Oracle客户端本身并不执行任何操作，其主要职责仅在于将客户端生成的SQL指令传递至服务器端。尽管客户端内也存在一个数据库进程，但它的功能与服务器端的进程存在差异。数据库进程仅在服务器上对SQL指令执行处理。需特别指出的是，在专用连接的背景下，客户端的进程与服务器端的进程是严格匹配的。换句话说，一旦客户端与服务器建立连接，双方各自都会启动一个进程，客户端的这个进程我们称之为客户端进程，而服务器端的对应进程则称为服务器进程。

第二步:语句解析

客户端将 SQL 命令发送至服务器，随后服务器进程将执行对该命令的解析操作。这一解析过程同样是在服务器端完成的。尽管这一过程仅涉及解析一项任务，但它实际上分为若干个具体步骤来执行。

检索共享资源。当服务器端接收到客户端发送的SQL指令后，并不会立即对数据库进行查询操作。相反，它会首先在数据库的共享资源中查找，看是否有与该指令相匹配的执行方案。若该SQL语句位于共享池内，服务器进程将直接从共享池中提取执行计划，并检查库高速缓存中是否存有所需数据。若数据已存在，则直接从库高速缓存中逻辑读取。若数据不在库高速缓存中，服务器进程将通过物理读操作，将所需数据从物理磁盘读取至库高速缓存，随后再将数据通过服务器进程发送至客户端。因此，若选用共享池，可以增强SQL语句的查询速度。若该语句尚未设定执行方案，则需执行后续步骤。

务器将尝试从数据字典缓存中进行查询。若缓存中亦无匹配的 SQL 语句，系统将启动合法性验证流程。

服务器进程随即启动对所述语句合法性的审核。这一过程主要涉及对 SQL 语句语法的审查，以确保其是否符合规范。

当服务器进程判定该SQL指令违反了语法规范时，它将把相应的错误信息传递给客户。

用户端。在执行语法审查时，系统不会对 SQL 语句中的表格名称、字段名称等要素进行 SQL 相关的检查，它仅限于语法层面的审查。

上的检查。

对语言含义进行核实（数据字典缓存）。一旦确认 SQL 语句在语法上正确无误，那么服务器进程将进行下一步操作。

接下来，我们将对语句中的字段和表格进行审查。我们将核实这些字段和表格是否已存在于数据库中。同时，我们还将对比表名与列名是否相匹配。

精确的表述，数据库便会向客户端发送错误反馈。因此，在编写select查询语句时，若语法出现不当，便可能引发此类问题。

若同时写错了表名或列名，系统会首先指出语法上的错误sql外连接执行顺序，只有当语法完全无误之后，才会进一步提示列名或表名的错误。

错误。

成功获取目标解析锁（控制结构）。一旦语法和语义均无误，系统便会着手处理我们所需查询的信息。

对目标对象实施锁定措施，其目的在于确保数据的一致性，避免在查询操作期间，其他用户对对象的结构或状态进行不当修改。

生改变。

确保拥有对数据的访问权限，即便语法和语义都通过了验证，客户端也未必能直接访问所需的数据。

成功获取数据后，服务器进程将进一步核实，你所接入的用户是否具备访问该数据的授权。只有在你与服务器成功建立连接之后，这一过程才会启动。

若用户缺乏数据访问权限，客户端便无法获取相关数据。在查询信息时，我们有时会感到颇为艰辛。

我们辛苦地编写并成功编译了 SQL 语句，然而，系统却给出了“无法访问数据”的提示，这让我们感到非常沮丧。

在开发前端应用软件并进行调试时，有时会遇到半死不活的状态。因此，我们必须重视这一问题，确保在操作中，数据库服务器的进程首先得到妥善处理。

检查语法与语义,然后才会检查访问权限。

确定最优执行方案后，即便语句无误且语法正确，权限也相匹配，服务器进程仍旧不会立即对

数据库文件进行检索。服务器进程会依照既定规则，对这一查询语句进行优化处理。然而，需留意的是，这种优化并非万能。

在软件开发的应用阶段，通常需要对数据库的SQL语句进行优化处理；这种优化效果极为显著，其重要性不容小觑。

因此，在开发应用程序的过程中，对数据库进行优化是不可或缺的环节。在这种情况下，服务器进程的自我调整就显得尤为重要。

在优化器选定该查询语句的最优执行方案之后，它便会将此 SQL 语句及其执行方案存入数据的高速缓存之中。

若采用（图书馆缓存），那么在将来再次执行此查询时，便可跳过那些语法、语义以及权限验证的环节。

而直接执行 SQL 语句,提高 SQL 语句处理效率。

第三步:语句执行

语句分析是对 SQL 语句的语法进行解读，其目的是确保服务器能够准确理解该语句所传达的具体含义。

思考完毕，语句被解析，随后数据库服务器的进程才会启动执行该SQL指令。这一执行过程同样分为两个阶段。

种情况。

若所选行对应的数据块已存入数据缓冲区，服务器进程将直接将该数据传递，无需再次读取。

直接向客户端提供数据，而非从数据库文件中检索。若缓冲区中无此数据SQL-执行过程详解，服务器进程将转而从数据库文件中查找所需数据，并将这些数据存入数据缓冲区（buffer cache）。

第四步:提取数据

在语句执行完毕时，所查询的数据依然停留在服务器进程之中，尚未被转移至客户端的进程。因此，

在服务器端程序中，存在一段特定的代码模块，该模块的主要职能是提取所需数据。此代码负责将检索到的信息反馈给

用户端进程得以启动，进而执行了整个查询操作。在这一系列查询处理流程中，我们参与了数据库的开发或应用软件的设计与开发工作。

程中,需要注意以下几点:

首先，必须明确数据库缓存与软件应用缓存是两个不同的概念。其次，数据库缓存仅存在于数据库服务器端，而并非在应用软件中。

客户端并不存在。唯有如此，方能确保数据库缓存中的数据与数据库文件中的数据保持同步。唯有如此，才能依据

相关规则旨在遏制数据的不当读取或误读现象。然而，应用软件中的数据缓存与数据库缓存性质迥异。

情感因素使得尽管应用软件的数据缓存能够提升数据检索的速度，然而，这种做法却违背了数据一致性的原则，有时甚至导致不一致的情况发生。

脏乱阅读或误读现象时有发生，因此，在一些应用软件中，通常会设置一个特定功能，以便在需要时能够进行清除。

数据缓存方面，需要指出的是，对数据缓存的清除操作，实际上仅限于本机上的数据缓存，换言之，仅限于当前应用程序的数据缓存。

的数据缓存,而不会清除数据库的数据缓存。

第二点，绝大多数的SQL指令均遵循这一处理流程执行。作为数据库管理员，抑或是依托Oracle数据库系统，

开发人员对这类语句的处理机制有深入了解，这对我们进行涉及SQL语句的开发与调试工作极为有益。此外，这也有助于我们更好地掌握相关技术。

在恰当的时机，遵循这些处理准则，有助于缩短我们排查问题的时长。尤其是要重视，数据库在数据查询权限的审核方面，将其置于核心位置。

在语法和语义方面进行审查后，因此，仅依靠数据库的权限管理规则，可能不足以完全满足应用软件的权限需求。

出于对权限的管控需求，此刻必须借助软件界面进行配置，以满足权限管理的具体要求。此外，在特定情况下，还需对应用数据库的权限进行有效管理。

理虽然略显复杂，这无疑会加大服务器的工作负担。鉴于此，在实施对记录、字段等信息的查询权限管理时，大多数程序都倾向于采取较为谨慎的策略。

序涉及人员喜欢在应用程序中实现,而不是在数据库上实现。

DBCC DROPCLEANBUFFERS

从缓冲池中删除所有清除缓冲区。

DBCC FREEPROCCACHE

从过程缓存中删除所有元素。

DBCC FREESYSTEMCACHE

从所有缓存中释放所有未使用的缓存条目

SQL语句中的函数、关键字、排序等执行顺序:

1. FROM 子句返回初始结果集。

2. WHERE 子句排除不满足搜索条件的行。

GROUP BY 子句的功能是将所选择的记录按照不同的唯一值进行归类，并将它们分别汇集到各个对应唯一值的组别中。

4. 选择列表中指定的聚合函数可以计算各组的汇总值。

5. 此外,HAVING 子句排除不满足搜索条件的行。

6. 计算所有的表达式;

7. 使用 order by 对结果集进行排序。

8. 查找你要搜索的字段。

二、SQL语句执行完整过程：

1.用户进程提交一个 sql 语句:

update temp set a=a*2，给服务器进程。

服务器进程在接收到用户进程的信息之后，便需要在PGA中为该进程分配必要的内存，以存储那些相关信息，例如在会议记录中。

话内存存储相关的登录信息等。

服务器进程将 SQL 语句中的字符转换成相应的 ASCII 数字，随后这些数字被发送至一个

执行HASH函数后得到一个hash码，随后服务器进程会在共享池的library cache中检索该hash码是否已存在，若找到匹配的hash码，服务器进程将直接使用存储在SHARED POOL的library cache中已分析过的语句版本来执行。

若该元素不存在，服务器进程将进入CGA阶段，与UGA内容协同对sql语句执行语法解析，首要任务是验证其语法结构的准确性，随后再进行后续操作。

对语句中包含的表格、索引、视图等元素进行深入分析，同时参照数据字典核实这些元素的命名和结构信息。接着，依据ORACLE所采用的优化策略，以及数据字典中是否有相关元素的统计信息和是否应用了存储概要，来制定一个执行计划或从存储概要中挑选一个执行计划。随后，利用数据字典来确认该用户对相关元素的执行权限，最终生成编译后的代码。

ORACLE 对该 SQL 语句的实际文本内容、其对应的 HASH 值、编译后的代码以及与之相关的各项统计数据进行了限制。

该语句的执行方案被存储在SHARED POOL的library cache缓存内。服务器进程利用SHARED POOL锁存器来确定哪些共享PL/SQL区域可以缓存相关信息。换句话说，被SHARED POOL锁存器所控制的PL/SQL区域内的数据块不会被替换，因为它们有可能被其他进程所访问。

在 SQL 的分析过程中，我们将会利用到 LIBRARYCACHE；而在对数据字典进行核对，确认表、视图等结构时，必须对数据进行

字典在将信息从磁盘导入LIBRARYCACHE时，必须先对LIBRARYCACHE进行锁定，即使用LIBRARYCACHE锁存器。

通过使用pin和library cache lock机制，我们申请了用于存储数据字典的缓存。截至目前，该SQL语句已被编译成可执行的指令，然而，具体要处理的数据尚未明确，因此服务器进程还需为该SQL语句准备必要的数据预处理工作。

首先，服务器进程需确认所需数据是否已存在于数据库缓冲区中；若数据确实存在并且可以访问，则直接提取该数据，同时依据

LRU算法会对访问计数进行提升；若buffer中不存在所需数据，便需从数据文件中读取。首先，服务器进程会在表头部申请TM锁（以此确保事务执行过程中其他用户无法修改表结构），若成功获取TM锁，再申请行级锁（TX锁），一旦TM锁和TX锁均成功锁定，便开始从数据文件中读取数据。在读取数据前，需先为读取的文件预留buffer空间。服务器进程需对LRU列表进行扫描以查找可用的数据库缓冲区，在扫描过程中，若发现任何已修改的db缓冲区，便会将其登记至脏列表。这些脏缓冲区随后会根据dbwr的激活条件被写入数据文件。一旦找到足够的空闲缓冲区，服务器进程便可以将请求的数据行对应的数据块置于db缓冲区的空闲区域，或者覆盖掉那些因被挤出LRU列表而变得非脏的数据块缓冲区，并将其置于LRU列表的顶端。在将数据块存入DBBUFFER之前，必须先申请db缓冲区的锁存器，只有成功获取锁存器后，才能将数据读入db缓冲区。

记录日志，目前数据已成功加载至数据库缓冲区，随后服务器进程将受该语句影响、已加载至数据库缓冲区的相关行数据的rowid、原始值、新值以及scn等信息，逐条写入重做日志缓冲区。在将数据写入重做日志缓冲区之前，必须先申请锁定该缓冲区的锁存器。只有在成功获取锁之后，才能进行写入操作。写入过程会持续进行，直到缓冲区容量达到其总容量的三分之一，或者写入的数据量达到1兆字节，或者经过三秒钟的等待，或者触发检查点事件，或者在数据库写入器（dbwr）执行之前。

一旦发生sql外连接执行顺序，lgwr进程便会将redo log buffer中的数据记录至磁盘上的redo file文件，同时，这一过程亦会引发log file的产生。

sync事件等待完成后，redofile的redo log buffer中所持有的锁存器将得到释放，随后这些锁存器可以被后续的写入数据所覆盖，而redo log buffer本身是循环利用的。重做日志文件同样遵循循环利用的原则，一旦某个重做日志文件被填满，日志写入进程（lgwr）便会自动转至下一个重做日志文件，在此过程中可能会遇到等待日志文件切换（检查点完成）的事件。若处于归档状态，归档操作需将上一个已满的重做日志文件中的数据转移至归档日志记录里，在此过程中sql外连接执行顺序，可能会遇到日志文件的问题。

switch(archiving needed)。

将事务列表的块头部信息录入scn，并将包含该事务列表及scn信息的副本复制至回滚段，该回滚段内的信息被称为数据块的前映像，该前映像将用于后续的回滚、恢复以及一致性读取操作。回滚段能够存放在特定的回滚表空间内，该表空间由一个或多个物理文件构成，并专门用于存放回滚段。此外，回滚段还可以在其他表空间的数据文件中进行配置。

本事务的数据块修改准备工作已全部完成，此刻我们已可着手修改db buffer块中的数据内容，同时，还需在数据块的起始部分进行记录。

入回滚段的地址。

将数据加入黑名单，若某行记录频繁更新却未完成提交，那么在回滚过程中将出现多个“旧版本”SQL-执行过程详解，除了第一个之外，其他均会存在。

除了“前映像”中包含scn信息之外，每一个“前映像”的头部均含有scn信息，并且还附有“前前映像”的回滚段地址。

更新操作仅针对单一SCN执行，随后服务器进程会在脏列表中创建一个

该指针指向该数据库缓冲区块，便于数据库写入进程(dbwr)定位脏列表中的数据库缓冲区数据块，进而写入数据文件。随后，服务器进程将自数据文件中读取第二个数据块，并重复对前一数据块的操作：读取数据块、记录日志、创建回滚段、修改数据块，并将其加入脏列表。一旦dirty queue的长度触及预设的阈值（通常为25%），服务器进程便会告知dbwr将脏数据输出，即解除db buffer上的锁定，从而为更多的空闲db buffer腾出空间。在此之前，我们一直在阐述Oracle每次仅读取一个数据块的过程，然而实际上，Oracle具备一次性读取多个数据块的能力。

通过db_file_multiblock_read_count参数来指定单次读取的块数量。

说明:

对于已经存放在数据库缓冲区中的预处理数据，或者是从数据文件中刚刚被加载至数据库缓冲区的数据，处理时需依据SQL指令进行操作。

的类型来决定接下来如何操作。

若为select指令，需检查数据库缓冲区块的起始部分是否存在事务，若存在，便需从回滚段中提取所需数据；同时，还需确认。

若无事务存在，需对比select语句的scn值与db buffer块首部的scn值，若前者数值偏低，则需从回滚段中提取数据；反之，若前者数值偏高，则表明该db buffer块非脏缓存，可径直读取其内容。

若涉及数据修改操作，即便在数据库缓冲区发现一个未涉及事务的记录，并且其系统变更号（SCN）低于当前操作，仍需执行相应的处理。

缓存中的数据单元，即便如此，服务器中的运行进程仍需对表首的该条信息提出锁定请求，只有锁定操作顺利完成，才能执行后续的操作；若锁定失败，进程便需暂停，直至前一个进程释放锁，方能继续动作（此时，进程处于事务锁阻塞状态）。

用户进行commit或rollback操作后，截至目前，数据已对db buffer或数据文件进行了相应的修改。

完成操作后，是否需要将更改永久保存至数据文件，这一选择权应交由用户自行决定；相应地，用户可以选择commit（将更改保存至数据文件）或rollback（撤销已做的数据更改）。

1.用户执行 commit 命令

只有当 SQL 语句所涉及的每一行数据所在的最终数据块已被加载至数据库缓冲区，同时重做操作的相关信息已被记录到重做日志中，

日志缓冲区（特指，非日志文件）处理完毕后，用户方得执行commit指令。此指令会激活lgwr进程，但并不会强制dbwr进程立刻释放所有对应的db buffer块锁（即no-force-at-commit，即提交操作不强制写入）。换言之，即便commit操作已完成，dbwr进程仍可能在接下来的时间里继续写入该sql语句涉及的数据块。表头部的行锁并非在提交操作完成后立刻解除，它需待数据库写入进程（dbwr）的任务执行完毕方才解除，因此，可能会出现一种情况，即一个用户的请求无法成功获取到另一用户已提交的资源。

在Commit进程与dbwr进程终止的间隔极短，若不幸在commit操作完成而dbwr进程尚未终止时遭遇断电，由于……

数据在执行commit操作后便构成了数据文件的一部分，然而，该文件并未将这部分内容完整地保存。因此，必须进行前滚操作。由于commit操作已激活了lgwr，所有尚未写入数据文件的变更将在系统重启时，由smon进程依据重做日志文件进行前滚，以完成之前commit未能完成的任务，即将这些变更记录写入数据文件中。

若在未执行提交操作的情况下系统突然断电，那么这表明数据已对数据库缓冲区进行了修改，而由于未进行提交，故此部分数据尚不属于数据库的正式记录。

根据文件记载，每当dbwr因数据变更而激活lgwr，即数据变更发生时，必须先有日志记录，因此DBWR对数据文件的任何修改都会优先记录在重做日志中。在实例重启之后，SMON进程会依据这些重做日志进行回滚操作。

实际上，smon的前滚回滚操作是基于检查点的执行，一旦所有检查点均被触发，首先启动LGWR进程来执行，然后，它将...

重做日志缓冲区内的所有缓冲区（包括尚未提交的重做记录）需被写入重做日志文件，随后dbwr进程需将数据库缓冲区中已提交的缓冲区内容写入数据文件，但未提交的缓冲区写入则非强制要求。接着，需更新控制文件和数据文件头部的系统变更号（SCN），以此表明数据库的一致性，同时指出在两个检查点之间，存在大量事务，包括已提交和未提交的。

像前面的前滚回滚比较完整的说法是如下的说明:

在检查点发生断电之前，同时还有一个未完成的变更正在进行中；实例重启后，SMON进程将自上一个检查点开始执行。

核对起始于检查点，随后需将此检查点之后的修改记录在重做日志文件里，包括已提交的变更以及尚未提交的改动。

在dbwr执行操作前，lgwr会先被激活，这意味着dbwr对数据文件所做的任何更改都将首先被记录在重做日志文件里。正因为如此，在断电之前进行的操作，其影响必然会被保留在重做日志中。

DBWN对数据文件所做的修改，会通过重做日志文件中的记录来恢复，这一过程被称为回滚。

若在断电发生之际，有一项事务已成功提交，而dbwr的修改操作尚未彻底完成，鉴于该事务已确认无误，其提交行为将激活lgwr。

无论dbwr的操作是否已经完成，该语句所影响的行及其产生的结果，均已记录于重做日志文件之中。因此，在实例重启之后，SMON进程将依据这些重做日志文件进行数据的前滚操作。

实例恢复所需的时间取决于两个检查点之间的时间跨度，这一跨度可通过以下四个参数来调整检查点的执行频率：Log_checkpoint_interval参数负责设定两个检查点间写入重做日志文件的系统物理块(redo blocks)的频率。

参数的尺寸上限未设定，其预设值为零，且没有上限限制。log_checkpoint_timeout：表示两个检查点之间所经历的时间长度（以秒为单位），其默认设定为1800秒。fast_start_io_target参数设定了在恢复过程中需处理的区块数量，其默认值为0，意味着无限制；而fast_start_mttr_target参数则直接影响了恢复所需的时间长度，同样默认为0，表示无时间限制。这一设定在SMON进程执行前滚操作时生效。

SMON与用户的回滚操作存在本质区别，SMON的操作是基于重做日志文件来执行前滚或回滚，而用户的回滚则是依据回滚段中的数据内容来执行回滚。在此需提及回滚段所保存的信息，若执行删除操作，回滚段会保留该行的全部数据；若是更新操作，它仅记录变更字段在变更前的数据（即前映像），未被修改的字段则不会被记录；至于插入操作，回滚段仅保存被插入记录的rowid。若事务执行了提交，那么在回滚段中只需对已提交的事务进行简单标注；若是进行回退操作，需根据不同情况处理：若操作为删除，则在回退时将回滚段中的数据重新写入数据块；若操作为更新，则需将变更前的数据恢复；若操作为插入，则需根据记录的rowid将该记录从数据中删除。

若用户执行回滚操作，服务器进程将依据数据文件块及DB BUFFER中块头部的事务列表、系统变更号（SCN）以及回滚段的位置信息，定位到回滚段内对应的修改前副本。随后，利用这些原始数据值，对当前数据文件中已变更但尚未提交的部分进行恢复。若存在多个“前映像”，服务器进程会在某个“前映像”的开头定位到“前前映像”的回滚段位置，并持续追踪，直至找到该事务下最早的“前映像”。一旦用户执行了COMMIT操作，便无法进行回滚，从而确保了COMMIT之后DBWR进程尚未完成的后续操作的安全性。截至目前，该事务已圆满结束。

说明：TM锁，即遵循lock机制的锁，旨在确保对象的定义不会被随意更改。TX锁，则代表一个事务，特指对数据库行级操作的锁定机制。

级锁，通过数据块头部和数据记录头部中特定字段的表示来实现，它遵循lock机制，涉及资源结构以及lock的多个方面。

structure、enqueue 算法。