Oracle实例主要有3 类进程：

（1）服务器进程（serverprocess）：这些进程根据客户的请求来完成工作。我们已经对专用服务器和共享服务器有了一定的了解。它们就是服务器进程。

（2）后台进程（backgroundprocess）：这些进程随数据库而启动，用于完成各种维护任务，如将块写至磁盘、维护在线重做日志、清理异常中止的进程等。

（3）从属进程（slaveprocess）：这些进程类似于后台进程，不过它们要代表后台进程或服务器进程完成一些额外的工作。

在某些操作系统（如Windows）上，Oracle使用线程实现，所以在这种操作系统上，就要把我们所说的“进程”理解为“线程”的同义词。

“进程”一词既表示进程，也涵盖线程。如果你使用的是一个多进程的Oracle 实现，比如说UNIX 上的Oracle 实现，“进程”就很贴切。如果你使用的是单进程的Oracle 实现，如Windows上的Oracle 实现，“进程”实际是指“Oracle 进程中的线程”。所以，举例来说，当我谈到DBWn 进程时，在Windows 上就对应为Oracle 进程中的DBWn 线程

服务器进程

服务器进程就是代表客户会话完成工作的进程。应用向数据库发送的SQL 语句最后就要由这些进程接收并执行。

（1）专用服务器（dedicatedserver）连接，采用专用服务器连接时，会在服务器上得到针对这个连接的一个专用进程。数据库连接与服务器上的一个进程或线程之间存在一对一的映射。

（2）共享服务器（sharedserver）连接，采用共享服务器连接时，多个会话可以共享一个服务器进程池， 其中的进程由Oracle 实例生成和管理。你所连接的是一个数据库调度器（dispatcher），而不是特意为连接创建的一个专用服务器进程。

注意连接和会话之间的区别：

（1）连接（connection）就是客户进程与Oracle 实例之间的一条物理路径（例如，客户与实例之间的一个网络连接）。

（2）会话（session）则不同，这是数据库中的一个逻辑实体，客户进程可以在会话上执行SQL 等。多个独立的会话可以与一个连接相关联，这些会话甚至可以独立于连接存在。

专用服务器进程和共享服务器进程的任务是一样的：要处理你提交的所有SQL。当你向数据库提交一个SELECT * FROM EMP 查询时，会有一个Oracle 专用/共享服务器进程解析这个查询，并把它放在共享池中（或者最好能发现这个查询已经在共享池中）。这个进程要提出执行计划，如果必要，还要执行这个执行计划，可能在缓冲区缓存中找到必要的数据，或者将数据从磁盘读入缓冲区缓存中。这些服务器进程是干重活的进程。在很多情况下，你都会发现这些进程占用的系统CPU 时间最多，因为正是这些进程来执行排序、汇总、联结等等工作，几乎所有工作都是这些进程做的。

专用服务器连接

在专用服务器模式下，客户连接和服务器进程（或者有可能是线程）之间会有一个一对一的映射。如果一台UNIX 主机上有100 条专用服务器连接，就会有相应的100 个进程在执行。可以用图来说明，如图1 所示。

客户应用中链接着Oracle 库，这些库提供了与数据库通信所需的API。这些API 知道如何向数据库提交查询，并处理返回的游标。它们知道如何把你的请求打包为网络调用，专用服务器则知道如何将这些网络调用解开。这部分软件称为Oracle Net，不过在以前的版本中可能称之为SQL*Net 或Net8。这是一个网络软件/协议，Oracle 利用这个软件来支持客户/服务器处理（即使在一个n 层体系结构中也会“潜伏”着客户/服务器程序）。不过，即使从技术上讲没有涉及Oracle Net，Oracle 也采用了同样的体系结构。也就是说，即使客户和服务器在同一台机器上，也会采用这种两进程（也称为两任务）体系结构。

这个体系结构有两个好处：

（1）远程执行（remoteexecution）：客户应用可能在另一台机器上执行（而不是数据库所在的机器），这是很自然的。

（2）地址空间隔离（addressspace isolation）：服务器进程可以读写SGA。如果客户进程和服务器进程物理地链接在一起，客户进程中一个错误的指针就能轻松地破坏SGA 中的数据结构。

共享服务器连接

共享服务器连接强制要求必须使用Oracle Net，即使客户和服务器都在同一台机器上也不例外。如果不使用OracleTNS 监听器，就无法使用共享服务器。如前所述，客户应用会连接到Oracle TNS 监听器，并重定向或转交给一个调度器。调度器充当客户应用和共享服务器进程之间的“导管”。图5-2 显示了与数据库建立共享服务器连接时的体系结构。

在此可以看到，客户应用（其中链接了Oracle 库）会与一个调度器进程物理连接。对于给定的实例，可以配置多个调度器，但是对应数百个（甚至数千个）用户只有一个调度器的情况并不鲜见。调度器只负责从客户应用接收入站请求，并把它们放入SGA 中的一个请求队列。第一个可用的共享服务器进程（与专用服务器进程实质上一样）从队列中选择请求，并附加相关会话的UGA（图2 中标有“S”的方框）。共享服务器处理这个请求，把得到的输出放在响应队列中。调度器一直监视着响应队列来得到结果，并把结果传回给客户应用。就客户而言，它分不清到底是通过一条专用服务器连接还是通过一条共享服务器连接进行连接，看上去二者都一样，只是在数据库级二者的区别才会明显。

连接与会话

在一条连接上可以建立0 个、一个或多个会话。各个会话是单独而且独立的，即使它们共享同一条数据库物理连接也是如此。一个会话中的提交不会影响该连接上的任何其他会话。实际上，一条连接上的各个会话可以使用不同的用户身份。

在Oracle 中，连接只是客户进程和数据库实例之间的一条特殊线路，最常见的就是网络连接。这条连接可能连接到一个专用服务器进程，也可能连接到调度器。如前所述，连接上可以有0 个或多个会话，这说明可以有连接而无相应的会话。另外，一个会话可以有连接也可以没有连接。使用高级Oracle Net 特性（如连接池）时，客户可以删除一条物理连接，而会话依然保留（但是会话会空闲）。客户在这个会话上执行某个操作时，它会重新建立物理连接。

连接（connection）：连接是从客户到Oracle 实例的一条物理路径。连接可以在网络上建立，或者通过IPC 机制建立。通常会在客户进程与一个专用服务器或一个调度器之间建立连接。不过，如果使用Oracle 的连接管理器（Connection Manager ，CMAN），还可以在客户和CMAN之间以及CMAN 和数据库之间建立连接。

会话（session）：会话是实例中存在的一个逻辑实体。这就是你的会话状态（session state），也就是表示特定会话的一组内存中的数据结构。提到“数据库连接”时，大多数人首先想到的就是“会话”。你要在服务器中的会话上执行SQL、提交事务和运行存储过程。可以使用SQL*Plus 来看一看实际的连接和会话是什么样子，从中还可以了解到，实际上一条连接有多个会话的情况相当常见。

这里使用了AUTOTRACE 命令，并发现有两个会话。我们在一条连接上使用一个进程创建了两个会话。以下是其中的第一个会话：

1. SQL> select username, sid, serial#, server,paddr, status from v$session where username='SYS';  

2. USERNAME                              SID    SERIAL# SERVER    PADDR   STATUS  

3. ------------------------------ -------------------- --------- -------- --------  

4. SYS                                   153         27 DEDICATED 3621B264 ACTIVE 

以上PADDR 列是这个专用服务器进程的地址。

下面，只需打开AUTOTRACE来查看SQL*Plus 中所执行语句的统计结果：

1. SQL> set autotrace on statistics  

2. SQL> select username, sid, serial#,server, paddr, status from v$session where username='SYS';  

3. USERNAME                              SID    SERIAL# SERVER    PADDR   STATUS  

4. ------------------------------ -------------------- --------- -------- --------  

5. SYS                                   152         88 DEDICATED 3621B264 INACTIVE  

6. SYS                                   153         27 DEDICATED 3621B264 ACTIVE  

7. Statistics  

8. ----------------------------------------------------------  

9. 0  recursive calls  

此时有了两个会话，但是这两个会话都使用同一个专用服务器进程，从它们都有同样的PADDR 值就能看出这一点。从操作系统也可以得到确认，因为没有创建新的进程，对这两个会话只使用了一个进程（一条连接）。

需要注意，其中一个会话（原来的会话）是ACTIVE（活动的）。这是有道理的： 它正在运行查询来显示这个信息，所以它当然是活动的。但是那个INACTIVE（不活动的）会话呢？那个会话要做什么？这就是AUTOTRACE 会话，它的任务是“监视”我们的实际会话，并报告它做了什么。

在SQL*Plus 中启用（打开）AUTOTRACE 时，如果我们执行DML 操作（INSERT、UPDATE、DELETE、SELECT和MERGE），SQL*Plus 会完成以下动作：

(1)如果还不存在辅助会话[1]，它会使用当前连接创建一个新会话。

(2)要求这个新会话查询V$SESSTAT视图来记住实际会话（即运行DML的会话）的初始统计值。

(3)在原会话中运行DML 操作。

(4)DML 语句执行结束后，SQL*Plus会请求另外那个会话（即“监视”会话）再次查询V$SESSTAT，并生成前面所示的报告，显示出原会话（执行DML 的会话）的统计结果之差。

如果关闭AUTOTRACE，SQL*Plus 会终止这个额外的会话，在V$SESSION 中将无法看到这个会话。你可能会问：“SQL*Plus 为什么要这样做，为什么要另建一个额外的会话？”。原因是：如果使用同一个会话来监视内存使用，那执行监视本身也要使用内存。

如果在同一个会话中观察统计结果，就会对统计结果造成影响（导致对统计结果的修改）。倘若SQL*Plus使用一个会话来报告所执行的I/O 次数，网络上传输了多少字节，以及执行了多少次排序，那么查看这些详细信息的查询本身也会影响统计结果。这些查询可能自己也要排序、执行I/O 以及在网络上传输数据等（一般来说都会如此！）。因此，我们需要使用另一个会话来正确地测量。

到目前为止，我们已经看到一条连接可以有一个或两个会话。现在，我们想使用SQL*Plus 来查看一条没有任何会话的连接。这很容易。在上例所用的同一个SQL*Plus 窗口中，只需键入一个“很容易误解”的命令即DISCONNECT：

从技术上讲，这个命令应该叫DESTROY_ALL_SESSIONS 更合适，而不是DISCONNECT，因为我们并没有真正物理地断开连接。

注意在SQL*Plus 中要真正地断开连接，应该执行“exit”命令，因为你必须退出才能完全撤销连接。不过，我们已经关闭了所有会话。

使用另一个用户账户打开另一个会话，并查询原用户SYS。

1. SQL> select username, sid, serial#,server, paddr, status from v$session where username='SYS';  

2. no rows selected 

可以看到，这个账户名下没有会话，但是仍有一个进程，相应地有一条物理连接（使用前面的ADDR值）：

1. SQL> select username, program fromv$process where addr = hextoraw('3621B264');  

2. USERNAME        PROGRAM  

3. ---------------------------------------------------------------  

4. oracle          oracle@db1 (TNS V1-V3) 

所以，这就有了一条没有相关会话的“连接”。可以使用SQL*Plus 的CONNECT 命令（这个命令的名字也起得不恰当），在这个现有的进程中创建一个新会话（CONNECT命令叫CREATE_SESSION更合适）：

1. SQL> conn / as sysdba;  

2. Connected.  

3. SQL> select username, sid, serial#,server, paddr, status from v$session where username='SYS';  

4. USERNAME                              SID    SERIAL# SERVER    PADDR   STATUS  

5. ------------------------------ -------------------- --------- -------- --------  

6. SYS                                   158         34 DEDICATED 3621B264 ACTIVE 

可以注意到，PADDR 还是一样的，所以我们还是在使用同一条物理连接，但是（可能）有一个不同的SID。我说“可能有”，是因为也许还会分配同样的SID，这取决于在我们注销时是否有别人登录，以及我们原来的SID 是否可用。

到此为止，这些测试都是用一条专用服务器连接执行的，所以PADDR 正是专用服务器进程的进程地址。