ORACLE深入 第四章 Oracle Processes

ORACLE深入 第四章 Oracle Processes

SERVER Background Background PROCESSES

CONNECT SESSION DEDICATE Shared Server Connections

日月明王BLOG：http://sunmoonking.spaces.live.com

ORACLE 的每一个 PROCESS 都会在 PGA 里分配一块 MEM 并执行相应的任务。分为以下三类：

SERVER PROCESSES ：基于 CLIENT 的请求。比如应用程序发往 DB 的 SQL

BACKGROUND PROCESSES: 在 DB 启动的时候启动 , 来保证 DB 的运行 .

SLAVE PROCESS: 执行 SERVER PROCESS 或 BACKGROUND PROCESS 的额外辅助工作 .

· 1 SERVER PROCESSES

先回顾下 DEDICATE SERVER 和 SHARED SERVER

DEDICATE SERVER: SERVER 分配一个单独的 PROCESS 提供点对点的连接 .

SHARED SERVER: CLIENT 连接的是 DISPATCHER 而不时 SERVER PROCESS.

再来理解下 CONNECT 和 SESSION 的异同 .

一个 CONNECT 是 CLIENT PROCESS 和 ORACLE INSTANCE 的物理路径 .

一个 SESSION 是一个逻辑实体 ( 用来执行 CLIENT 的 SQL 等 ).

一个 CONNECTION 由 0 个 ,1 个 , 或多个独立的 SESSIONS 组成 . 一个 SESSION 的 COMMIT 并不影响在相同 CONNECTION 里的其他 SESSION.

可以证明下 ,

本测试在 DEDICATE SERVER 环境下

select username, sid, serial#, server, paddr, status

2 from v$session

3* where username ='SBTOPT'

SQL> /

USERNAME SID

------------------------------------------------------------ ----------

SERIAL# SERVER PADDR STATUS

---------- ------------------ ---------------- ----------------

SBTOPT 32

38431 DEDICATED 070000004DA3B550 INACTIVE

SQL> set autotrace on statistics

select username, sid, serial#, server, paddr, status

2 from v$session

3* where username ='SBTOPT'

SQL> /

USERNAME SID

------------------------------------------------------------ ----------

SERIAL# SERVER PADDR STATUS

---------- ------------------ ---------------- ----------------

SBTOPT 32

38431 DEDICATED 070000004DA3B550 INACTIVE

SBTOPT 35

62380 DEDICATED 070000004DA3B550 ACTIVE

可以看到两个 SESSION 用同一个 SERVER PROCESS, 有着同一个 PADDR, 看到 STATUS 一个是 ACTIVE, 另一个是 INACTIVE,STATUS 在这里就不解释了 .

此时大家可能有个疑问 , 这个时候有两个 SESSION, 那么我在运行一个 DML STATEMENT, 这两个 SESSIO 会如何协同工作呢 ?

1, 用新的 SESSION(SID 35) 去查询 V$SESSTAT 来记录运行 DML STATEMENT(SID 32) 的初值 ,.

2, SID32 上运行 DML

3,SID 35 会再查 V$SESSTAT, 并产生 TRACE 报告 .

那你可能又有新问题了 , 为什么会这样呢 ? 用一个 SESSION 不行吗 ? 回答当然是不行 , 因为如果是一个 SESSION 那么就无法区分那些 I/O, 网络传输的字节 ,SORTS 等是因为 DML 还是因为跟踪产生的 . 所有的这些都会累计到 STATISTICS. 所以需要另一个 SESSION 去统计这些数据 .

到这里 , 我们看到了一个 CONNECTION 由 1 个 , 或多个独立的 SESSIONS 组成 . 前面说过 , 一个 CONNECTION 由 0 个 ,1 个 , 或多个独立的 SESSIONS 组成 , 下面看看一个 CONNECT 由 0 个 SESSION 组成的情况 .

在 B 窗口 ,

SQL> disconnect

Disconnected from Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production

With the Partitioning, OLAP and Oracle Data Mining options

JServer Release 9.2.0.6.0 - Production

SQL>

A 窗口再看

SQL>

select username, sid, serial#, server, paddr, status

2 from v$session

3* where username ='SBTOPT'

已经没有数据了 .

不管是 DEDICATE 还是 SHARED SERVER 都做相同的工作 , 那就是把你给他的 SQL 提供给 DB 然后 ORACLE DEDICATE/SHARED SERVER PROCESS 解析 (PARSE) 然后放到 SHARED POOL( 或者在 SHARED POOL 发现已经存在就不用解析 ), 然后按 QUERY PLAN 执行 , 此时可能从 BUFFER CACHE 里读或从 DISK 里做物理读 .( 取决于是否在 BUFFER CACHE 里发现需要的数据 )

DEDICATE SERVER

CLIENT 和 SERVER 不管是不是在同一个机器上面 , 都会用 NET 连接 . 在 SERVER 上运行 CLIENT 的时候可以用下面的 SQL 来看产生一个连接的父子进程

1 select a.spid dedicated_server,

2 b.process clientpid

3 from v$process a, v$session b

4 where a.addr = b.paddr

5* and b.sid = (select sid from v$mystat where rownum=1) /* 仅举例子而已 , 所以取一条记录 */

SQL> /

DEDICATED_SERVER CLIENTPID

------------------------ ------------------------

581982 602440

这两个值一样则表示在同一机器上 . 前者 spid 是 OS PID, 后者看 PS 进程 .

orasbp@svodbp01:$ ps -ef|grep 581982

orasbp 581982 602440 0 15:48:22 - 0:00 oracleSBP (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

orasbp@svodbp01:$ ps -p 602440

PID TTY TIME CMD

602440 pts/4 0:00 sqlplus

可以看到 602440 是父 , 581982 是子 , 而真正执行 QUERY 的正式 581982.

DEDICATE SERVER 的 TRANSACTION 之间相互独立 , 互不影响 , 所以 , 如果硬件 (CPU,MEM) 足够为每一个 TRANSACTION 分配资源 , 那么几千个同时 CONNECT 也是没什么问题的 .

Shared Server Connections

SHARED SERVER 即使是在 CLIENT,SERVER 在一个机器上也必须用 LISTENER.

SHARED SERVER 只适合 sort, frequence transactions. 90% 以上是比较短平快的 transactions 就可以考虑使用 SHARED SERVER.

如果你要使用 Oracle Net connection pooling 的话那也需要设置 shared server. 但是 , 如果你已经采用了其他的 connection pooling 技术 (EG: J2EE connection pool),, 那么用 SHARED SERVER 就没什么好处了 .

SHARED SERVER 可以减少 System Processes/Threads. 但是 SHARED SERVER 下的 session trace( 比如设置 SQL_TRACE=TRUE) 可能会导致一个 SESSION 有多个 trace files, 这就导致要想得到此 session 的工作情况变得非常困难 .

但是 , 一般情况下还是建议用 DEDICATE, 除非系统真的过载 (overload)

· 2 Background Processes

大家都记得 ORACLE INSTANCE 的定义吧 , ORACLE INSTANCE 是由 SGA 和 background process 组成 . background process 维持着 DB 的正常运行 .

下面 SQL 得到所有可能的 background process

1 select paddr||' '|| name||' '||description

2 from v$bgprocess

3* order by paddr desc

SQL> /

PADDR||''||NAME||''||DESCRIPTION

--------------------------------------------------------------------------------

070000004DA3A608 ARC1 Archival Process 1

070000004DA3A0F0 ARC0 Archival Process 0

070000004DA39BD8 CJQ0 Job Queue Coordinator

070000004DA396C0 RECO distributed recovery

070000004DA391A8 SMON System Monitor Process

070000004DA38C90 CKPT checkpoint

070000004DA38778 LGWR Redo etc.

070000004DA38260 DBW0 db writer process 0

070000004DA37D48 PMON process cleanup

00 DIAG diagnosibility process

00 FMON File Mapping Monitor Process

PADDR 非 00 的就是你的系统里正在运行的 background process.

首要 Background Processes

PMON: 负责在 SERSSION 断掉之后负责释放 SGA 资源 , rollback of uncommitted work, 释放 lock, 此外 , 还会监控其他 background processes, 并在必要的时候重起

SMON: 清理零时空间（ eg: CREATE INDEX 被 abort ），合并自由空间（ DMT ， pctincrease 非 0 ）， RECOVER ， RAC 中一个 INSTANCE 失败后其它 NODE 会打开此失败的 INSTANDE 的 REDO LOG 并 RECOVER ， strinks rollback segments 。

RECO ： …

CKPT ： CKPT 更新 DATA FILES 的 files head 。 8.0 之后此进程是必须的进程了（以前更新 DATA FILES 的 files head 的任务是由 LGWR 完成的，现在可以说是 CKPT 减轻了 LGWR 的工作强度）。

DBWn ：从 buffer cache 写 dirty blocks 到 disk 。写的时候是异步 IO （ asynchronous I/O ）， DBWn 手机 BLOCK 然后把它们交给 OS ，此时 DBWn 并不等待 OS 写完而直接去收集下批 BLOCK 。 OS 写完后会告诉 DBWn 可以再发下批数据了。

LGWR ：比较像 DBWn ，只是写的时 REDO 。触发需要以下任何一个条件（ COMMIT ， 3 秒， redo log buffer 1/3 满），所以一个大的 redo log buffer 并没有好处，因为它可能并没有完全用到。

ARCn: 当 LGWR 写满 online redo log file 后 ARCH 写到磁盘上 ,

ASMB :Automatic Storage Management Background : ASM

RBAL(Rebalance process ) : ASM

LMON (Lock monitor process) : RAC

LMD (Lock manager daemon ) process :RAC

LMSn (Lock manager server ) process :RAC

LCK0( Lock process) :RAC

DIAG (Diagnosability daemon ) process :RAC

次要 Background Processes

这些 background process 是可选的 , 基于你的需求 . 并不需要每天运行 ( 除非你设置成 JOB) .

CJQ0( Job queues), 最多可以有 1000 个进程 , 因为没一个 JOB QUEUE PROCESS 在一个时间只为一个 JOB 服务 , 这就是我们为什么如果想同时跑多个 JOB 必须设置成多 PROCESS 的原因 . CJQ0是一个协调者,他会根据字典里的信息来判断是否该触发一个Jnnn PROCESS来完成任务.

Q000(AQ queue proces )

QMNC (AQ monitor process)

MMAN( Automatic SGA sizing enabled)