Oracle Server Architecture
An Oracle server uses memory structures and processes to manage and access the database. All memory structures exist in the main memory of the computers that constitute the database system. Processes are jobs that work in the memory of these computers.
An Oracle server consists of an Oracle database and an Oracle server instance. Every time a database is started, a system global area (SGA) is allocated and Oracle background processes are started. The combination of the background processes and memory buffers is called an Oracle instance.
The architectural features discussed in this article enable the Oracle server to support:
- Many users concurrently accessing a single database
- The high performance required by concurrent multiuser, multiapplication database systems
Figure 1 shows a typical variation of the Oracle server memory and process structures.
Figure 1 Memory Structures and Processes of Oracle
Memory Structures
Oracle creates and uses memory structures to complete several jobs. For example, memory stores program code being run and data shared among users. Two basic memory structures are associated with Oracle:
- System global area, and
- Program global area
System Global Area
The System Global Area (SGA) is a shared memory region that contains data and control information for one Oracle instance. Oracle allocates the SGA when an instance starts and deallocates it when the instance shuts down. Each instance has its own SGA.
Users currently connected to an Oracle server share the data in the SGA. For optimal performance, the entire SGA should be as large as possible (while still fitting in real memory) to store as much data in memory as possible and to minimize disk I/O.
The information stored in the SGA is divided into several types of memory structures, including:
-
Database buffers: store the most recently used blocks of data. The set of database buffers in an instance is the database buffer cache. The buffer cache contains modified as well as unmodified blocks. Because the most recently (and often, the most frequently) used data is kept in memory, less disk I/O is necessary, and performance is improved.
-
Redo log buffer: stores redo entries--a log of changes made to the database. The redo entries stored in the redo log buffers are written to an online redo log, which is used if database recovery is necessary. The size of the redo log is static.
-
Shared pool: contains shared memory constructs, such as shared SQL areas. A shared SQL area is required to process every unique SQL statement submitted to a database. A shared SQL area contains information such as the parse tree and execution plan for the corresponding statement. A single shared SQL area is used by multiple applications that issue the same statement, leaving more shared memory for other uses.
-
Large pool(optional): provides large memory allocations for Oracle backup and restore operations, I/O server processes, and session memory for the shared server and Oracle XA (used where transactions interact with more than one database).
-
Statement Handles or Cursors. A cursor is a handle (a name or pointer) for the memory associated with a specific statement. (Oracle Call Interface, OCI, refers to these as statement handles.) Although most Oracle users rely on automatic cursor handling of Oracle utilities, the programmatic interfaces offer application designers more control over cursors. For example, in precompiler application development, a cursor is a named resource available to a program and can be used specifically to parse SQL statements embedded within the application. Application developers can code an application so it controls the phases of SQL statement execution and thus improves application performance.
Process Architecture
A process is a "thread of control" or a mechanism in an operating system that can run a series of steps. Some operating systems use the terms job or task. A process generally has its own private memory area in which it runs.
An Oracle server has two general types of processes: user processes and Oracle processes.
User (Client) Processes
User processes are created and maintained to run the software code of an application program (such as a Pro*C/C++ program) or an Oracle tool (such as Enterprise Manager). User processes also manage communication with the server process through the program interface.
Oracle Processes
Oracle processes are invoked by other processes to perform functions on behalf of the invoking process. The different types of Oracle processes and their specific functions are discussed in the following sections.
Server Processes
Oracle creates server processes to handle requests from connected user processes. A server process communicates with the user process and interacts with Oracle to carry out requests from the associated user process. For example, if a user queries some data not already in the database buffers of the SGA, then the associated server process reads the proper data blocks from the datafiles into the SGA.
Oracle can be configured to vary the number of user processes for each server process. In a dedicated server configuration, a server process handles requests for a single user process. A shared server configuration lets many user processes share a small number of server processes, minimizing the number of server processes and maximizing the use of available system resources.
On some systems, the user and server processes are separate, while on others they are combined into a single process. If a system uses the shared server or if the user and server processes run on different machines, then the user and server processes must be separate. Client/server systems separate the user and server processes and run them on different machines.
Background Processes
Oracle creates a set of background processes for each instance. The background processes consolidate functions that would otherwise be handled by multiple Oracle programs running for each user process. They asynchronously perform I/O and monitor other Oracle process to provide increased parallelism for better performance and reliability.
Each Oracle instance can use several background processes. The names of these processes are DBWn, LGWR, CKPT, SMON, PMON, ARCn, RECO, Jnnn, Dnnn, LMS, and QMNn.
Database Writer (DBWn)
The database writer writes modified blocks from the database buffer cache to the datafiles. Although one database writer process (DBW0) is sufficient for most systems, you can configure additional processes (DBW1 through DBW9 and DBWa through DBWj) to improve write performance for a system that modifies data heavily. The initialization parameter DB_WRITER_PROCESSES specifies the number of DBWn processes.
Because Oracle uses write-ahead logging, DBWn does not need to write blocks when a transaction commits. Instead, DBWn is designed to perform batched writes with high efficiency. In the most common case, DBWn writes only when more data needs to be read into the SGA and too few database buffers are free. The least recently used data is written to the datafiles first. DBWn also performs writes for other functions, such as checkpointing.
Log Writer (LGWR)
The log writer writes redo log entries to disk. Redo log entries are generated in the redo log buffer of the SGA, and LGWR writes the redo log entries sequentially into an online redo log. If the database has a multiplexed redo log, then LGWR writes the redo log entries to a group of online redo log files.
Checkpoint (CKPT)
At specific times, all modified database buffers in the SGA are written to the datafiles by DBWn. This event is called a checkpoint. The checkpoint process is responsible for signaling DBWn at checkpoints and updating all the datafiles and control files of the database to indicate the most recent checkpoint.
System Monitor (SMON)
The system monitor performs recovery when a failed instance starts up again. With Real Application Clusters, the SMON process of one instance can perform instance recovery for other instances that have failed. SMON also cleans up temporary segments that are no longer in use and recovers terminated transactions skipped during recovery because of file-read or offline errors. These transactions are eventually recovered by SMON when the tablespace or file is brought back online. SMON also coalesces free extents in the dictionary managed tablespaces to make free space contiguous and easier to allocate.
Process Monitor (PMON)
The process monitor performs process recovery when a user process fails. PMON is responsible for cleaning up the cache and freeing resources that the process was using. PMON also checks on dispatcher and server processes and restarts them if they have failed.
Archiver (ARCn)
The archiver copies the online redo log files to archival storage after a log switch has occurred. Although a single ARCn process (ARC0) is sufficient for most systems, you can specify up to 10 ARCn processes by using the dynamic initialization parameter LOG_ARCHIVE_MAX_PROCESSES. If the workload becomes too great for the current number of ARCn processes, then LGWR automatically starts another ARCn process up to the maximum of 10 processes. ARCn is active only when a database is in ARCHIVELOG mode and automatic archiving is enabled.
Recoverer (RECO)
The recoverer is used to resolve distributed transactions that are pending due to a network or system failure in a distributed database. At timed intervals, the local RECO attempts to connect to remote databases and automatically complete the commit or rollback of the local portion of any pending distributed transactions.
Job Queue Processes (Jnnn)
Job queue processes are used for batch processing. Job queue processes are managed dynamically. This enables job queue clients to use more job queue processes when required. The resources used by the new processes are released when they are idle.
Dispatcher (Dnnn)
Dispatchers are optional background processes, present only when a shared server configuration is used. At least one dispatcher process is created for every communication protocol in use (D000, . . ., Dnnn). Each dispatcher process is responsible for routing requests from connected user processes to available shared server processes and returning the responses back to the appropriate user processes.
Lock Manager Server (LMS)
The Lock Manager Server process (LMS) is used for inter-instance locking in Real Application Clusters.
Queue Monitor (QMNn)
Queue monitors are optional background processes that monitor the message queues for Oracle Advanced Queuing. You can configure up to 10 monitor processes.