11 GConcepts (chapter 2) ProcessArchitecture (process Architecture)

Chapter 2 Process Architecture)

This chapter discusses the processes of Oracle databases.

This chapter contains the following sections:

· Introduction to Processes

· Overview of Client Processes

· Overview of Server Processes

· Overview of Background Processes

Introduction to Processes (process Introduction)

A process is an operating system mechanism that can run consecutive steps. This mechanism depends on the operating system. For example, a background process in Oracle on Linux is a linux Process. On Windows, there is only one thread in the oracle.exe process.

Run the code module through a process. All users connected to the Oracle database must run the following modules to access the database instance:

· Applications or Oracle Database Utilities

A database user runs database applications, such as pre-compiled programs or database tools such as SQL * Plus, and issues SQL statements to the database.

· Oracle Database code

Each user runs Oracle Database code for it to explain and process the SQL statements of the application.

A process runs normally in its private memory area. Most processes periodically write a related trace file.

Multiple-Process Oracle Database Systems (multi-Process Oracle Database System)

Multiple-process Oracle (also known as a multiuser database) uses several processes to run different parts of the Oracle database code, and additional processes are provided to users (either a process serves one user or one or more processes share and process multiple users ). Most databases have multiple users, because the main advantage of a database is to manage multiple users to send requests to a certain data at the same time.

The process of each database instance executes a special task. By splitting the database and putting it in some processes, multiple users and applications can connect to an Instance at the same time, and the system will provide good performance.

Types of Processes (process type)

A database instance contains these types of processes, or interacts with these process types.

· Client processes (Client process) Running reference or Oracle tool code

· Oracle processes (Oracle process) runs the Oacle database code. Oracle processes includes the following two subtypes:

The OBackground processes (background process) is started with the instance and performs maintenance tasks such as executing instance recovery, cleaning the process, and writing redo buffers to the disk.

OServer processes (Service Process) executes client-based requests

For example, these processes parse SQL queries and place them in the sharedpool to create and execute a query plan for each query, and read the buffer from buffercache or from the disk.

Note: server process and the memory allocated by these processes are all running in the instance. The Instance is still running after the server processes is stopped.

OSlave processes (subordinate process) executes additional tasks for a background or server process.

Changes in the process structure depend on the operating system and the selection of Database options. For example, the connection user code can be set to dedicated server or shared server connection mode. In the shared server architecture, the database code running on each server process can serve multiple client processes.

In the afternoon, it is displayed that the connection mode of an SGA and background process is dedicated. The application runs through the client process. Unlike the dedicated server process, the server process runs the database code. Each client process has its own server process (the server process has its own PGA ).

Overview of Client Processes (Client process Overview)

When a user runs an application similar to a Pro * C program or SQL * Plus program, the operating system creates a client process (sometimes called a user process) to run the user's application. The Client application has a connected Oracle Database Class Library, which provides the APIs required for communication with the database.

Client and Server Processes (customer process and service process)

The Client process differs from the Oracle process in that the Oracle process interacts directly with the instance. The Oracle process serving the client process can read and write data in SGA, but the client process cannot. A client process can run on a host other than the Database Host, but the Oracle process does not.

For example, assume that a user runs SQL * Plus on the client host and the database sample that is connected to different hosts through the network (the database instance has not yet started ):

SQL> CONNECT SYS @ inst1 AS SYSDBA

Enter password :*********

Connected to an idle instance.

On the client host, if the process is sqlplus or sample, only the sqlplus process is displayed:

% ps -ef | grep -e sample -e sqlplus | grep -v grep

clientuser 29437 29436  0 15:40 pts/1    00:00:00 sqlplus           as sysdba

On the server host, if the Query Process is sqlplus or sample, a non-local connection service process is displayed:

% ps -ef | grep -e sample -e sqlplus | grep -v grep

serveruser 29441     1  0 15:40 ?        00:00:00 oraclesample (LOCAL=NO)

Connections and Sessions (connection and session)

A Connection is a physical Connection between the client process and database instance. A connection path is established by using the connection mechanism between processes or network software. Basically, a connection occurs between a client process and a server process, or between a client process and a dispatcher, but it can usually be established between the client process and Oracle Connection Manager (CMAN.

A session is a logical existence in a database instance. It represents the status of a user logging on to the database. For example, a session is created when a user/password is verified by the database. The time for a session to exist is from the authentication passed until the user disconnect or exits the database application.

A single connection can have 0, 1 or even multiple sessions. These sessions are independent: A session commit operation does not affect transactions in other sessions.

NOTE: If your lenet connection pooling (connection pool, something in the sharing mode) is configured, the connection may also be disconnected, but the session will not be affected.

Multiple sessions can exist at the same time and are all database users. As shown in, the user hr can have multiple connections. In VPC connection mode, the database creates a dedicated server process for each connection. Only the client process that causes it to be created can use it. In the shared connection mode, many client processes can access a shared server process.

 

It is shown that hr has a connection, but this connection has two sessions.
 

The autotrace report that generates an SQL statement can reproduce this situation.

Example: A connection has two sessions.

SQL> SELECTSID, SERIAL #, PADDR FROM V $ SESSION WHERE USERNAME = USER;

Sid serial # PADDR

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

90 91 3BE2E41C

SQL> SETAUTOTRACE ON STATISTICS;

SQL> SELECTSID, SERIAL #, PADDR FROM V $ SESSION WHERE USERNAME = USER;

Sid serial # PADDR

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

88 93 3BE2E41C

90 91 3BE2E41C

SQL> DISCONNECT

The DISCONNECT Command actually interrupts the session, instead of the connection. It opens a new interrupt, connects to the instance through different users, and then queries it through the following query, we can see that the above connect (connection) is still active

SQL> CONNECTdba1 @ inst1

Password :********

Connected.

SQL> SELECTPROGRAM FROM V $ PROCESS WHERE ADDR = HEXTORAW ('3be2e41c ');

PROGRAM

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

Oracle @ stbcs09-1 (TNS Co., V1-V3)

Overview of Server Processes (Service Process Overview)

The Oracle database creates a server process to process client process requests. A client process always accesses the database through a separate serverprocess.

The service process corresponding to a database application can execute one or more of the following tasks:

· Parse and execute SQL statements published through applications, including creating and executing a query plan)

· Execute PL/SQL code

· Read data blocks from database files to buffer cache (DBWn background processes write dirty data to disks quickly)

· The application can process the returned results.

Dedicated Server Processes)

In VPC connection mode, the client connection is associated with only one service process. In LINUX, 20 client processes are connected to instances, so 20 service processes are waiting for them.

Each client process communicates directly with the service process. This service process is proprietary throughout the entire session cycle of the client process. The server process stores the unique information of the process and UGA to its own PGA.

Shared Server Processes)

In the shared service connection mode, the client application connects to a dispatcher process (scheduling process) over the network, instead of a server process. For example, 20 client processes can be connected to a separate dispatcher process.

The Dispatch process will accept the requests sent from the client connected to it, and then publish the requests to the Request queue of large pool. The first available shared server process obtains this request from the queue and processes it. After processing, the shared server process places the results in the dispatcher response (response) queue. The Dispatcher process listens to this queue and sends the result back to the client)

Like the proprietary connection mode, the shared server process also has its own PGA. However, the UGA of a session is in SGA, so that any shared server process can access the session data.

Overview of Background Processes (Background process Overview)

A multi-process database uses some additional processes, which are called background processes. backend processes need to maintain database operations and provide maximum performance to multiple users.

Each background process has its own independent task, but it will work with other processes. For example, the LGWR process writes data in the redo log buffer to the online redo log file. When the file is full, the file can be archived. LGWR sends a signal to other processes to archive the file.

Oracle database automatically creates background processes when the instance is started. A single instance may have many background processes. In different database configurations, not all background processes will exist.

The following query lists which background processes are running in your database:

SELECT PNAME

From v $ PROCESS

WHERE PNAME IS NOT NULL

Order by pname;

This section contains the following topics:

· Mandatory Background Processes

· Optional Background Processes

· Slave Processes

Mandatory Background Processes (Force Background process)

Mandatory background processes exists in the standard database configuration. When the instance starts with the minimum parameter configuration, they all run by default.

This section describes the following mandatory background processes:

· Process Monitor Process (PMON)

· System Monitor Process (SMON)

· Database Writer Process (DBWn)

· Log Writer Process (LGWR)

· Checkpoint Process (CKPT)

· Manageability Monitor Processes (MMON and MMNL)

· Recoverer Process (RECO)

Process Monitor Process (PMON) (Process Monitor)

The Process monitor (PMON) monitor other processes and reclaim them when the server or dispatcher Process ends abnormally. PMON is responsible for clearing the buffer cache used by the client process and releasing resources. For example, PMON will reset the status of related transactions in the transaction table (for example, set it to a non-action), release unnecessary locks, and remove the process ID from the active process list.

PMON also registers information about the instance and dispatcherprocess to the Oracle Net listener (listener ). When an instance is started, the PMON round-robin listener is used to determine whether the listener is running. If the listener is running, PMON sends the relevant parameters to it. If the listener is not running, PMON periodically tries to contact it.

System Monitor Process (SMON) (System Monitor Process)

System monitor process (SMON) is responsible for cleaning various System levels. The tasks assigned to SMON include:

· Execute instance recovery, if necessary, during the instance startup phase. In Oracle RAC, the SMON of an instance can perform instance recovery for a faulty instance.

· During the instance recovery period, transactions that do not have a recovery ing because of files or tablespace offline will be recovered when the tablespace and files are restored to online.

· Clean up without using temporary segments. For example, when creating an index, the database will assign some extent to it. If an error occurs in the operation, then SMON will clean up these temporary spaces.

· In the tablespace of the dictionary-managed (dictionary management), the connected idle extents are merged.

SMON periodically checks whether something is needed. Other processes can notify SMON to process SMON when detecting where SMON is needed.

Database Writer Process (DBWn) (Database write Process)

DBWn writes the content in buffers to a data file. The DBWn process writes the buffer modified in buffercache to the disk. Although a write process (DBW0) is sufficient in most systems, you can still configure additional processes DBW1 to DBW9 and DBWa to DBWj, to increase the Write Performance (if your system modifies a lot of data)

These attached DBWn processes are useless in the unique process system.

The DBWn process writes dirty buffer to the disk when the following conditions are met:

· When a server process does not find a clean reusable buffer after scanning a large number of buffers (exceeding a threshold), the server process sends a signal to DBWn, let it write. DBWn writes dirty buffer asynchronously as much as possible to execute other processing at the same time.

· DBWn periodically writes the dirty buffer to promote the checkpoint. The checkpoint refers to the start point on the redo log when the instance is restored. The checkpoint on the log depends on the oldest dirty buffer in the buffer cache.

In most cases, the blocks written by DBWn are deleted discretely on the disk. Therefore, it is usually slower than the sequential write speed of LGWR. DBWn tries its best to execute multiple writes to improve efficiency. The number of block writes varies with the operating system.

Log Writer Process (LGWR) (log Write Program)

LGWR manages redo log buffer. LGWR writes a continuous part of the log buffer to the onlineredo log file. This improves the performance of the entire database by separating tasks from discrete writes of dirty buffer to the disk (LGWR is sequential write.

In the following case, LGWR writes all redo entries in the buffer from the last write to the disk:

· The user submits a transaction

· An online log switch occurs.

· Three seconds after the last LGWR write

· When the redo log buffer is 1/3 full or 1 MB

· DBWn write and modify buffers to disk

Before DBWn writes dirty buffer, the redorecords related to these dirty buffer must have been written to the disk (write-ahead protocol ). If DBWn finds that some related redo records have not been written, it sends a signal to LGWR to write these records to the disk. After LGWR is written, it writes the dirty buffer to the disk.

LGWR and Commits (LGWR and submit)

Oracle databases use the fast commit mechanism to improve transaction commit performance. When a user publishes a COMMIT statement, the transaction is assigned a system change number (SCN ). LGWR writes a commit record to the redo log buffer and writes this record and the transaction-related record to the disk immediately.

Redo log buffer is used cyclically. When LGWR writes redo entries in redo logbuffer to the redo log file, the newly copied entries of the server process can overwrite the written entries. Normally, LGWR writes fast enough to ensure that the buffer space is always sufficient, even if there are many redo logs.

The transaction commit record is used as a separate redo entry to determine whether the transaction is committed. After the transaction record is written to the disk, even if the related data buffers have not been written to the disk, however, the Oracle database returns that the submission is successful. Changes related to data blocks will be delayed until DBWn can write them to data files more effectively.

Note: LGWR can be written to the redolog file before the transaction is committed. Only after the transaction is committed will these entries become permanent.

When a transaction commits a dense set, LGWR can use group commits. For example, if one user commits, LGWR writes the redo entry related to the transaction to the disk. During this write process, other users also submit the redo entry, LGWR can write these commits only after the write is submitted. After the previous write is complete, LGWR can write all the entries of the transactions waiting for writing in one operation. In this way, the database reduces disk I/O and increases performance. If a request is submitted frequently, each LGWR write may contain multiple submitted records.

LGWR and Inaccessible Files (LGWR and Inaccessible Files)

LGWR writes all files in the redo log active group. If one file in the group is inaccessible, LGWR will continue to write other files in the group, and then write an error to the LGWR trace file and alert log File. If all files in the group are corrupted or the group is temporarily unavailable (because the archive is not completed), LGWR stops working.

Checkpoint Process (CKPT) (Checkpoint Process)

CKPT updates the checkpoint information to the control file, the data file header, and sends a signal to DBWn to write blocks to the disk. The checkpoint information includes the position of the checkpoint, the SCN, the online redo log, and so on. As shown in, CKPT does not write data blocks to Data Files Or redo entries to online redo log files.

 

Manageability Monitor Processes (MMON and MMNL) (Manageability monitoring process)

MMON executes many tasks related to Automatic WorkloadRepository (AWR. For example, when a metric value exceeds the threshold, a snapshot is created, and statistics of the objects recently modified by SQL are captured, a write operation is performed.

Manageability monitor lite process (MMNL), which writes statistics from ActiveSession History (ASH) buffer in SGA to the disk. When the ASH buffer is full, MMNL writes it to the disk.

Recoverer Process (RECO)

In the distributed database (database connected through DBLINK), recover process (RECO) automatically handles the error distributed transactions. In a two-phase commit transaction, the RECO process of one node automatically connects to other involved databases. When RECO reconstructs a connection between databases, it automatically rolls back all two-phase transactions, remove all the rows associated with the rollback transaction image in the pending transaction table in the database.

Optional Background Processes (Optional Background process)

The optional process is any background process (except the mandatory process ). The vast majority of optional background processes are for some tasks or features. For example, the process of Oracle Streams Advanced Queuing (QA) or OracleAutomatic Storage Management (Oracle ASM) is started only when these features are enabled.

This section describes some common optional processes:

· Archiver Processes (ARCn)

· Job Queue Processes (CJQ0 and Jnnn)

· Flashback Data Archiver Process (FBDA)

· Space Management Coordinator Process (SMCO)

Archiver Processes (ARCn) (archive process)

When a redo log switch occurs, the ARCn process is responsible for copying the online redo log file to the archive location. These processes can also collect transaction redo data and then transmit them to the standby database (DG) location. These processes exist only when the database is ARCHIVELOG mode and automatic archiving is enabled.

Job Queue Processes (CJQ0 and Jnnn) (job Queue process)

The Oracle database uses the job queue process to run users' jobs. A job is a customized and scheduled task (run once or multiple times ). For example, you can use job queue (job queue) to preset an update that runs for a long time and run it in the background. For a start date and interval, the job queue process will try to run the job after the next interval

The Oracle Database dynamically manages job queue processes. Therefore, more job queue processes can be enabled when necessary. When the process is idle, the Database releases the resources they use.

The Dynamic job queue process 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 job coordination process) will be automatically started or closed according to OracleScheduler's needs. The jobs that need to be run in the select JOB $ table of the coordinating process periodically.

2. Coordinate the process to dynamically generate jobqueue slave processes (Jnnn) to run jobs

3. The Job queue process runs one of the jobs selected by the CJQ0 process. Each job queue process can run only one job at a time until it is completed.

4. After a job is executed by a process, it polls other jobs. If no job needs to run, it enters sleep state and will wake up periodically to perform polling. If the process does not find any new job, it will terminate after the preset interval.

The initialization parameter JOB_QUEUE_PROCESSES is set to the maximum number of job queue processes that can be run concurrently in the instance.

NOTE: If JOB_QUEUE_PROCESSES is set to 0, the job coordination process will not start.

Flashback Data Archiver Process (FBDA) (flash back to the Data archiving Process)

The FBDA process Archives the historical rows of the tracked table to FlashbackData Archives. when a transaction is in the tracked table DML and the transaction is committed, the process will store the pre-image of these operated rows to Flashback Data Archive. It also saves the metadata as before.

FBDA automatically manages the space, structure, and storage time of flash back dataarchive. In addition, process stores a trace to show how long the transaction of the archived row occurred.

Space Management Coordinator Process (SMCO) (Space Management coordination Process)

SMCO process coordination and task-related execution of multiple types of space management, such as pre-Space Division and space recovery. SMCO dynamically generates the younger brother process (Wnnn) to execute the task.

Slave Processes (Slave process, or younger brother process)

The younger brother process is a younger brother process that works for other processes. This section describes the processes used by Oracle databases.

I/O Slave Processes (I/O Slave process)

The I/O slave process (Innn) simulates one-step I/O on systems and hardware that do not support asynchronous I/O. Asynchronous I/O, no time required for transmission, so that other processes can start before the transmission is complete

For example, if an application writes 1000 blocks to an operating system that does not support asynchronous I/O, each write is sequential, write continues only after the previous write is complete. On an asynchronous I/O disk, an application can write blocks in batches and then perform other work while waiting for the notification to be completed.

To simulate asynchronous I/O, a process manages several hard processes. Invoker process assigns work to each slave process, which waits for each write to complete and reports the call process after completion.

In the real asynchronous I/O, the operating system waits for the I/O to end and reports it to the process. When asynchronous I/O is simulated, the slave process will wait and report it to the caller.

The Database supports the following types of I/O slave processes:

· The I/O slave process used by the rediscovery Manaer (RMAN)

When using RMAN to back up or recover data, you can use the I/O slave process on disk and tape hardware.

· Database writer slaves (the Database is written to its slave process)

If the server has only one CPU, it is unrealistic to use multiple DBWn. In this case, the database can distribute I/O to multiple slave processes. DBWR is the only process that scans the buffercache LRU list to find the block to be written to the disk. the I/O slave process performs I/O operations on these blocks.

Parallel Query Slaves (Parallel Query slave)

In parallel execution (parallel execution), server processes, as parallel execution coordinator (parallel execution coordinator), have the responsibility to parse queries, allocate and control slave processes, and push results to users. A query plan for SQL queries is provided. The Coordinator splits each (operators) operation in the execution plan into parallel slices and runs them in the order specified in the query, then the slave process executes these (operators) results and then integrates them.

Displays parallel scans for the employees table. Dynamic table partition (or dynamic partition) is the loading unit, which is called granules ). A granule is some blocks in the table and is read and processed by a slave process. This process is called parallel execution server. It uses Pnnn as the name format.

 

The database maps granules to the execution server during execution. When an execution server reads rows from the corresponding granule. As well as the remaining granules, it will get another granule from the Coordinator. This operation will continue until the table is read. Execution servers pushes the results back to the coordinator, which assembles these slices into the required full table scan.

The number of Parallel executin servers in a single operation is the degree ofparallelism (degree of parallelism) of an operation ). Multiple operations in an SQL statement have the same degree of parallelism.