天天看点

Process Architecture

Process Architecture:

进程运行Code Modules,Each process in a database instance performs a specific job.

进程类型:

1、Client processes

2、Oracle processes

Client processes:run the application or oracle tool code.

Oracle processes:run the oracel database code.

Oracle processes包含3种类型:Background Processes,Server Processes,Slave Processes

Background Processes:instance启动时启动,perform maintenance tasks,例如:instance recovery,cleaning up processes,writing redo log buffers to disk等。

Server Processes:perform work based on a client request,例如:parse SQL queries,place them in the shared pool,为查询create or execute查询计划,从database buffer cache或disk读取数据。

Slave Processes: perform additional tasks for a background or server process.

进程结构跟操作系统和数据库options的选择有关。例如:连接用户的code可以被配置为dedicated server 或者shared server连接。配置为shared server的情况下,一个server process可以为多个client process服务。

1、Client processes

当用户run an user application(如:Pro*C或者sqlplus)时,操作系统会创建一个client process来run the user application。The client application has Oracle Database libraries linked into it that provide the APIs required to communicate with the database.

1.1 Client and Server Processes

Client and Server Processes:Client process 和 Oracle process跟instance的交互方式不同。Oracel process服务于Client process,可以从SGA中读写数据,而Client process不可以。Client process可以在非database host上运行,而Oracle process不可以。

1.2 Connections and Sessions

A connection 是一个client process和database instance通讯的路径。Typically, a connection occurs between aclient process and aserver process or dispatcher, but it can also occur between aclient process andOracle Connection Manager (CMAN).

A sessions是一个存在于the database instance memeory的逻辑实体。A session represents 当前登录数据库用户的state。

可以在一个connection上建立0个或多个session。各个session是独立的,一个session的提交不影响其他session的transactions。

一个用户可以同时存在多个session。

一个connection一个session:

Process Architecture

一个connection多个session:

Process Architecture

DISCONNECT命令不结束connection,只结束sessesions:

Process Architecture

2、Server Processes

Server processes可以做如下工作:

  • Parse and run SQL statements issued through the application, including creating and executing the query plan
  • Execute PL/SQL code
  • Read data blocks from data files into the database buffer cache (the DBWn background process has the task of writing modified blocks back to disk)
  • Return results in such a way that the application can process the information

2.1Dedicated Server Processes

In dedicated server connections, the client connection is associated with one and only one server process. On Linux, 20 client processes connected to a database instance are serviced by 20 server processes.

Each client process communicates directly with its server process. This server process is dedicated to its client process for the duration of the session. The server process stores process-specific information and the UGA in its PGA.

2.2Shared Server Processes

In shared server connections, client applications connect over a network to a dispatcher process, not a server process. For example, 20 client processes can connect to a single dispatcher process.

The dispatcher process receives requests from connected clients and puts them into a request queue in thelarge pool. The first available shared server process takes the request from the queue and processes it. Afterward, the shared server place the result into the dispatcher response queue. The dispatcher process monitors this queue and transmits the result to the client.

Like a dedicated server process, a shared server process has its own PGA. However, the UGA for a session is in the SGA so that any shared server can access session data.

3.Background Processes

当数据库instance启动时oracle database自动创建background Processes。一个instance可以有很多background process,但不是所有的background process always exist in every database configuration。

--查询运行在数据库中的后台进程:
SELECT PNAME 
FROM   V$PROCESS 
WHERE  PNAME IS NOT NULL 
ORDER BY PNAME;
           

3.1Mandatory Background Processes

The mandatory background processes are present in all typical database configurations. These processes run by default in a database instance started with a minimally configured initialization parameter file.

Process Monitor Process(PMON):

a、PMON监测其它的background process

b、当server or dispatcher process反常终止的时候进行process recovery

c、负责clean up the database buffer cache

d、释放the client process使用的资源

For example, PMON resets the status of the active transaction table, releases locks that are no longer required, and removes the process ID from the list of active processes.

PMON also registers information about the instance and dispatcher processes with the Oracle Net listener。When an instance starts, PMON polls the listener to determine whether it is running. If the listener is running, then PMON passes it relevant parameters. If it is not running, then PMON periodically attempts to contact it.

System Monitor Process(SMON):

The system monitor process (SMON) is in charge of a variety of system-level cleanup duties. The duties assigned to SMON include:

a、在实例启动的时候进行instance recovery。

b、Recovering在instance recovery中由于file-read or tablespace offline errors被跳过的terminated transactions。

c、Cleaning up unused temporary segments。

d、Coalescing contiguous free extents within dictionary-managed tablespaces。

SMON checks regularly to see whether it is needed. Other processes can call SMON if they detect a need for it.

Database Writer Process(DBWn):

将database buffer cache中的数据写入disk。

Log Writer Process(LGWR):

LGWR管理redo log buffer。LGWR将连续的redo log buffer写入online redo log。

在以下情况下LGWR开始写入online redo log:

a、A user commits a transaction

b、An online redo log switch occurs

c、Thress seconds have passed since LGWR last wrote

d、DBWn must write modified buffers to disk

Before DBWn can write a dirty buffer, redo records associated with changes to the buffer must be written to disk (thewrite-ahead protocol). If DBWn finds that some redo records have not been written, it signals LGWR to write the records to disk and waits for LGWR to complete before writing the data buffers to disk.

LGWR and Commits:

数据库用fast commit机制来提高事物提交的性能。当用户执行commit时,transaction被分配system change number(SCN)。LGWR将commit record放入redo log buffer,并立即将the commit SCN和transaction's redo entries写入到disk。

redo log buffer中的数据被写入online redo log后,server processes 可以将新的redo entries写入刚才的buffers。

 LGWR and Inaccessible Files:

LGWR writes synchronously to the active mirrored group of online redo log files. If a log file is inaccessible, then LGWR continues writing to other files in the group and writes an error to the LGWRtrace file and the alert log. If all files in a group are damaged, or if the group is unavailable because it has not been archived, then LGWR cannot continue to function.

 Checkpoint Process(CKPT):

 The checkpoint process (CKPT) updates the control file and data file headers with checkpoint information and signals DBWn to write blocks to disk. 

 Checkpoint information includes the checkpoint position, SCN, location in online redo log to begin recovery, and so on.

Manageablity Monitor Process(MMON and MMNL):

The manageability monitor process (MMON) performs many tasks related to theAutomatic Workload Repository(AWR). For example, MMON writes when a metric violates its threshold value, taking snapshots, and capturing statistics value for recently modified SQL objects.

The manageability monitor lite process (MMNL) writes statistics from the Active Session History (ASH) buffer in the SGA to disk. MMNL writes to disk when the ASH buffer is full.

Revoerer Process(RECO):

In a distributed database , the  recoverer process (RECO)  automatically resolves failures indistributed transactions . The RECO process of a node automatically connects to other databases involved in an in-doubt distributed transaction. When RECO reestablishes a connection between the databases, it automatically resolves all in-doubt transactions, removing from each database's pending transaction table any rows that correspond to the resolved transactions.

3.2Optional Background Processes

Archiver Processes(ARCn): 

The archiver processes(ARCn) 在一个redo log switch之后将online redo log files拷贝到offline storage。 These processes can also collect transaction redo data and transmit it tostandby database destinations.

只有在 ARCHIVELOG mode 并且automatic archiving is enabled的情况下ARCn进程才存在。

Job Queue Processes(CJQ0 and Jnnn):

Oracle数据库用Job Queue Processes来运行user jobs。

Dynamic job queue processes can run a large number of jobs concurrently at a given interval. The sequence of events is as follows:

  1. The job coordinator process (CJQ0) is automatically started and stopped as needed by Oracle Scheduler (see "Oracle Scheduler"). The coordinator process periodically selects jobs that need to be run from the system 

    JOB$

     table. New jobs selected are ordered by time.
  2. The coordinator process dynamically spawns job queue slave processes (Jnnn) to run the jobs.
  3. The job queue process runs one of the jobs that was selected by the CJQ0 process for execution. Each job queue process runs one job at a time to completion.
  4. After the process finishes execution of a single job, it polls for more jobs. If no jobs are scheduled for execution, then it enters a sleep state, from which it wakes up at periodic intervals and polls for more jobs. If the process does not find any new jobs, then it terminates after a preset interval.

初始化参数JOB_QUEUE_PROCESSES决定了一个实例上可以同时运行的最大job queue process数。

当初始化参数JOB_QUEUE_PROCESSES被设置为0时,The coordinator processes 不能被启动。

Flashback Data Archiver Process(FBDA):

The flashback data archiver process (FBDA) archives historical rows of tracked tables into Flashback Data Archives. When a transaction containing DML on a tracked table commits, this process stores the pre-image of the rows into the Flashback Data Archive. It also keeps metadata on the current rows.

FBDA automatically manages the flashback data archive for space, organization, and retention. Additionally, the process keeps track of how far the archiving of tracked transactions has occurred.

Space Management Coordinator Process(SMCO):

The SMCO process coordinates the execution of various space management related tasks, such as proactive space allocation and space reclamation. SMCO dynamically spawns slave processes (Wnnn) to implement the task.

3.3Slave Processes

 I/O Slave Processes:

Parallel Query Slaves: