5. Oracle starts an instance, then mounts a database to the instance.
6. Multiple instances can execute concurrently on the same machine, each accessing its own physical database.

The Oracle's process architecture is designed to maximize performance.

1. A process is a "thread of control" or a mechanism in an operating system that can execute a series of steps.
2. Some operating systems use the terms job or task.
3. A process normally has its own private memory area in which it runs.

Two goals of a process structure might be

• to simulate a private environment for multiple processes to work simultaneously, as though each process has its own private environment
• to allow multiple processes to share computer resources, which each process needs, but no process needs for long periods of time

Multi-user Oracle uses several processes to execute different parts of Oracle, and a separate process for each connected user.

• In a multiple-process system, processes can be categorized into two groups: user processes and Oracle processes.
• Each process in a multiple-process Oracle instance performs a specific job.
• By dividing the work of Oracle and database applications into several processes, multiple users and applications can simultaneously connect to a single database instance while the system maintains adequate performance.
• Most database systems are multi-user, because one of the primary benefits of a database is managing data needed by multiple users at the same time.

In a multiple-process system, processes are categorized into two groups: User Processes and Oracle Processes

When a user runs an application program, such as a Pro*C program, or an Oracle tool, such as Server Manager, Oracle creates a user process to run the user's application.

2- Oracle Processes

There are two types: server processes and background processes.

1. parse and execute SQL statements issued via the application
2. read necessary data blocks from disk (datafiles) into the shared database buffers of the SGA, if the blocks are not already present in the SGA
3. return results in such a way that the application can process the information

Lock (LCKn)

With the Parallel Server option, up to ten Lock processes (LCK0, . . ., LCK9) provide inter-instance locking. However, a single LCK process (LCK0) is sufficient for most Parallel Server systems. See Oracle7 Parallel Server for more information about this background process.

With the distributed option, up to ten Snapshot Refresh processes (SNP0, ..., SNP9) can automatically refresh table snapshots. These processes wake up periodically and refresh any snapshots that are scheduled to be automatically refreshed. If more than one Snapshot Refresh process is used, the processes share the task of refreshing snapshots.

1. Performs all writing of buffers to datafiles.
2. Is responsible for buffer cache management.

1. When a buffer in the buffer cache is modified, it is marked "dirty".
2. DBWR keeps the buffer cache "clean" by writing dirty buffers to disk.
3. As buffers are filled and dirtied by user processes, the number of free buffers diminishes. If the number of free buffers drops too low, user processes that must read blocks from disk into the cache are not able to find free buffers. DBWR manages the buffer cache so that user processes can always find free buffers.
4. A LRU (least recently used) algorithm keeps the most recently used data blocks in memory

The DBWR process writes dirty buffers to disk under these conditions:

LGWR normally writes fast enough to ensure that space is always available in the buffer for new entries, even when access to the redo log is heavy.

1. writes the redo log buffer to a redo log file on disk.
2. LGWR is responsible for redo log buffer management. LGWR writes all redo entries that have been copied into the buffer since the last time it wrote.

LGWR writes one contiguous portion of the buffer to disk. LGWR writes:

• a commit record when a user process commits a transaction
• redo buffers every three seconds
• redo buffers when the redo log buffer is one-third full
• redo buffers when the DBWR process writes modified buffers to disk

1. performs instance recovery at instance start up.
2. SMON is also responsible for cleaning up temporary segments that are no longer in use
3. it also combines contiguous free extents to make larger blocks of free space available.
4. In a Parallel Server environment, SMON performs instance recovery for a failed CPU or instance

SMON "wakes up" regularly to check whether it is needed. Other processes can call SMON if they detect a need for SMON to wake up.

The Process Monitor (PMON)

1. performs process recovery when a user process fails.
2. PMON is responsible for cleaning up the cache and freeing resources that the process was using. For example, it resets the status of the active transaction table, releases locks, and removes the process ID from the list of active processes.
3. PMON periodically checks the status of dispatcher and server processes, and restarts any that have died (but not any that Oracle has killed intentionally).

Like SMON, PMON "wakes up" regularly to check whether it is needed, and can be called if another process detects the need for it.

• Is a process used with the distributed option that automatically resolves failures involving distributed transactions.
• When the RECO process re-establishes a connection between involved database servers, it automatically resolves all in-doubt transactions.
• The RECO process automatically removes rows corresponding to any resolved in-doubt transactions from each database's pending transaction table.

If the RECO process attempts to establish communication with a remote server, and the remote server is not available or the network connection has not been re-established, RECO automatically tries to connect again after a timed interval. However, RECO waits an increasing amount of time (growing exponentially) before it attempts another connection.

The RECO background process of an instance is only present if the system permits distributed transactions.

• Without a dispatcher, each user process would require one dedicated server process.
• With the multi-threaded server, fewer shared server processes are required for the same number of users.

1. When an instance starts, the listener opens and establishes a communication pathway through which users connect to Oracle.
2. Each dispatcher gives the listener an address at which the dispatcher listens for connection requests.
3. When a user process makes a connection request, the listener process examines the request and determines if the user can use a dispatcher. If so, the listener process returns the address of the dispatcher process with the lightest load and the user process directly connects to the dispatcher.

The following example is a simple illustration of the dedicated server architecture of Oracle:

1. A database server machine is currently running Oracle using multiple background processes.
2. A client workstation runs a database application (in a user process) such as SQL*Plus. The client application attempts to establish a connection to the server using a SQL*Net driver.
3. The database server is currently running the proper SQL*Net driver. The Listener process on the database server detects the connection request from the client database application and creates a dedicated server process on the database server on behalf of the user process.
4. The user executes a single SQL statement. For example, the user inserts a row into a table.
5. The dedicated server process receives the statement. At this point, two paths can be followed to continue processing the SQL statement:

• If the shared pool contains a shared SQL area for an identical SQL statement, the server process can use the existing shared SQL area to execute the client's SQL statement.
• If the shared pool does not contain a shared SQL area for an identical SQL statement, a new shared SQL area is allocated for the statement in the shared pool.

6. The server process retrieves data blocks from the actual datafile, if necessary, or uses data blocks already stored in the buffer cache in the SGA of the instance.
7. The server process executes the SQL statement stored in the shared SQL area. Data is first changed in the SGA. It is permanently written to disk when the DBWR process determines it is most efficient to do so. The LGWR process records the transaction in the online redo log file only on a subsequent commit request from the user.
8. If the request is successful, the server sends a message across the network to the user. If it is not successful, an appropriate error message is transmitted.
9. Throughout this entire procedure, the other background processes are running and watching for any conditions that require intervention. In addition, Oracle is managing other transactions and preventing contention between different transactions that request the same data.

These steps show only the most basic level of operations that Oracle performs.