oracle的工作机制

引用

ORACLE的工作机制-1

    我们从一个用户请求开始讲,ORACLE的简要的工作机制是怎样的,首先一个用户进程发出一个连接请求,如果使用的是主机命名或者是本地服务命中的主机名使用的是机器名(非IP地址)，那么这个请求都会通过DNS服务器或HOST文件的服务名解析然后传送到ORACLE监听进程,监听进程接收到用户请求后会采取两种方式来处理这个用户请求,下面我们分专用服务器和共享服务器分别采用这两种方式时的情况来讲：

专用服务器模式下：一种方式是监听进程接收到用户进程请求后，产生一个新的专用服务器进程，并且将对用户进程的所有控制信息传给此服务器进程，也就是说新建的服务器进程继承了监听进程的信息，然后这个服务器进程给用户进程发一个RESEND包，通知用户进程可以开始给它发信息了，用户进程给这个新建的服务器进程发一个CONNECT包，服务器进程再以ACCEPT包回应用户进程，至此，用户进程正式与服务器进程确定连接。我们把这种连接叫做HAND-OFF连接，也叫转换连接。另一种方式是监听进程接收到用户进程的请求后产生一个新的专用服务器进程，这个服务器进程选用一个TCP/IP端口来控制与用户进程的交互，然后将此信息回传给监听进程，监听进程再将此信息传给用户进程，用户进程使用这个端口给服务器进程发送一个CONNECT包，服务器进程再给用户进程发送一个ACCEPT包，至此，用户进程可以正式向服务器进程发送信息了。这种方式我们叫做重定向连接。HAND-OFF连接需要系统平台具有进程继承的能力，为了使WINDOWS NT/2000支持HAND-OFF必须在HKEY_LOCAL_MACHINE>SOFTWARE>ORACLE>HOMEX中设置USE_SHARED_SOCKET。

共享服务器模式下：只有重定向连接的方式，工作方式是监听进程接收到用户进程的请求后产生一个新的调度进程，这个调度进程选用一个TCP/IP端口来控制与用户进程的交互，然后将此信息回传给监听进程，监听进程再将此信息传给用户进程，用户进程使用这个端口给调度进程发送一个CONNECT包，调度进程再给用户进程发送一个ACCEPT包，至此，用户进程可以正式向调度进程发送信息了。可以通过设置MAX_DISPIATCHERS这个参数来确定调度进程的最大数目，如果调度进程的个数已经达到了最大，或者已有的调度进程不是满负荷，监听进程将不再创建新的调度进程，而是让其中一个调度进程选用一个TCP/IP端口来与此用户进程交互。调度进程每接收一个用户进程请求都会在监听进程处作一个登记，以便监听进程能够均衡每个调度进程的负荷，所有的用户进程请求将分别在有限的调度进程中排队，所有调度进程再顺序的把各自队列中的部分用户进程请求放入同一个请求队列，等候多个ORACLE的共享服务器进程进行处理（可以通过SHARED_SERVERS参数设置共享服务器进程的个数），也就是说所有的调度进程共享同一个请求队列，共享服务器模式下一个实例只有一个请求队列，共享服务器进程处理完用户进程的请求后将根据用户进程请求取自不同的调度进程将返回结果放入不同的响应队列，也就是说有多少调度进程就有多少响应队列，然后各个调度进程从各自的响应队列中将结果取出再返回给用户进程。

以上我们讲完了用户与ORACLE的连接方式，下面我们要讲ORACLE服务器进程如何处理用户进程的请求，当一个用户进程发出了一条SQL语句：UPDATE TABBLEA SET SALARY=SALARY*2；首先服务器进程将对该语句进行检查语句有效性的语法检查和确保语句能够正常运行的语义检查，首先检查该语句的语法的正确性（语法检查），接着对照数据字典对语句中涉及的表、索引、视图等对象及用户的权限进行检查（语义检查），如果以上任一检查没有通过，就返回一个错误，但不会明确的指出是语法检查出错还是语义检查出错，它只会返回一个ORA-*****的错误码。如果检查通过以后，服务器进程把这条语句的字符转换成ASCII等效数字码（注意SQL中使用*是个例外，如果表的字段改变了，同样是SELECT * FROM TABLEA转换成的ASCII是不同的，其实它在语义检查时就明确的变成了操作具体字段的SQL语句了），接着这个ASCII码被传递给一个HASH函数，并返回一个HASH值，服务器进程将到SHARED POOL的共享PL/SQL区去查找是否存在同样的HASH值，如果存在，服务器进程将使用这条语句已高速缓存在SHARED POOL中的已分析过的版本来执行（软解析），如果不存在，则必须进行以下两个步骤：语句的优化(生成执行计划)和生成执行编码：服务器进程根据ORACLE选用的优化模式以及数据字典中是否存在相应对象的统计数据和是否使用了存储大纲来生成一个执行计划或从存储大纲中选用一个执行计划，最后再生成一个编译代码（硬解析）。（这里要注意的是，语法语义分析在前，计算HASH_VALUE在后，算出HASH_VALUE后只要找到相同的HASH_VALUE就使用这条缓存执行计划，语义分析在前确保了用户的使用权限等问题，不存在算出HASH_VALUE，再找到相同HASH_VALUE缓存执行计划而不能使用的情况。也不是先算HASH_VALUE，然后找缓存执行计划，找到后再语义检查这个步骤也是错的）ORACLE将这条语句的本身实际文本、HASH值、编译代码、与此语句相关联的任何统计数据和该语句的执行计划缓存在SHARED POOL的共享PL/SQL区。V$librarycache中的几个参数解释Pins: (Execution)即SQL实际执行的次数，不包括用户提交的语法语义检查失败的SQL。Reloads: (Parse)未找到相同HASH_VALUE的次数，即必须进行硬解析的次数。Invalidations: (Parse)因对象更改，使得所有引用这个对象的缓存执行计划失效而必须再次硬解析的次数。只要DDL更改了一个对象，所有与此有关的缓存在共享池中执行计划都将立即失效，它的失效不是在下次执行SQL时才发现其失效，而是DDL更改对象后立即就失效。主要表现在DDL发生后v$sql的HASH_VALUE仍保持不变，但PLAN_HASH_VALUE立即变为0,再次运行SQL语句时则会向v$sql插入一条新的缓冲记录HASH_VALUE，PLAN_HASH_VALUE都重新计算。原来的缓冲记录仍然还存在。


服务器进程通过SHARED POOL锁存器来申请可以向哪些共享PL/SQL区中缓存这些内容，也就是说被SHARED POOL锁存器锁定的PL/SQL区中的块不可被覆盖，因为这些块可能正在被其它进程所使用。在SQL分析阶段将用到LIBRARY CACHE，从数据字典中核对表、索引、视图及用户的权限的时候，需要将数据字典从磁盘读入LIBRARY CACHE，因此，在读入之前也要使用LIBRARY CACHE锁存器来申请用于缓存数据字典。