A database instance (also called a server) is a collection of storage structures and background processes used to access a set of database files. It enables a single database to be accessed by multiple instances (that is, ORACLE Parallel Server - OPS).
Instances are identified by ORACLE_SID in the operating system and by the parameter INSTANCE_NAME in Oracle, both of which have the same value. When the database is started, the system first allocates the system global area (SGA) in the server memory, which constitutes the memory structure of Oracle, and then starts several operating system processes that reside in the memory, which constitute the process structure, memory area and background process of Oracle. Collectively referred to as an Oracle instance.
Oracle Server
An Oracle Server consists of an Oracle instance and an Oracle database.
That is: Oracle Server = Oracle Instance + Oracle Database
Oracle instance
includes memory structure (SGA) and a series of background processes (Background Process)
namely: Oracle Instance = SGA + Background Process
Oracle memory structure
includes system global area (SGA) and program global Area (PGA)
is Oracle Memory Structures = SGA + PGA
SGA is shared by server and background process.
PGA contains data and control information of a single server process or a single background process. Contrary to SGA shared by several processes, PGA is only used by one process. The area used by the PGA is allocated when the process is created and reclaimed when the process is terminated. That is, generated by the server process.
oracle instance
One, memory structures
1. System Global Area (SGA)
SGA is a group of shared memory structures allocated for the system, which can contain data or control information of a database instance. If multiple users connect to the same database instance, in the instance's SGA, data can be shared by multiple users. When the database instance starts, the SGA memory is automatically allocated; when the database instance shuts down, the SGA memory is reclaimed. SGA is an area that occupies the largest memory, and it is also an important factor affecting database performance.
Mainly include:
1) Data block buffer cache (data block buffer cache)
The data block buffer cache is a cache area in the SGA, used to store data blocks (such as tables and tables) that read data segments from the database , indexes, and clusters). The size of the data block buffer is determined by the DB_LOCK_BUFFERS parameter in the database server init.ora file (represented by the number of database blocks). Resizing the block cache is an important part of tuning and managing a database.
Because the block buffer has a fixed size and is usually smaller than the space used by database segments, it cannot load all database segments in memory at once. Usually, the data block cache is only 1% to 2% of the database size, and Oracle uses the least recently used (LRU, least recently used) algorithm to manage the available space. When the storage area needs free space, the least recently used block will be moved out and the new data block will take its place in the storage area. In this way, the most frequently used data is kept in the storage area.
However, if the SGA is not large enough to hold all the most frequently used data, then different objects will contend for space in the block buffer. This is most likely to happen when multiple applications share the same SGA. At this point, each app's most recently used segment will compete with other apps' most recently used segments for space in the SGA. As a result, data requests to the data block cache will have a lower hit rate, resulting in reduced system performance.
The size is determined by db_cache_size
View: show parameter db_cache_size;
set: alter system set db_cache_size=800M;
2) Redo log buffer (redo log buffer cache)
redo items describe the modifications made to the database. They are written to the online redo log files for use in roll-forward operations during database recovery. However, before being written to the online redo log file, the transaction is first recorded in the SGA called the redologbuffer. The database can optimize this operation by periodically writing the contents of redo items to the online redo log file in batches. The size (in bytes) of the redo log buffer is determined by the LOG_BUFFER parameter in the init.ora file.
3) Shared pool: It is the most critical memory segment in SGA. The shared pool is mainly composed of library cache (shared SQL area and PL/SQL area) and data dictionary cache. Its function is to store frequently used SQL, Under the limited capacity, the database system decides when to release the SQL in the shared pool according to a certain algorithm.
The size of the library cache is determined by shared_pool_size
View: show parameter shared_pool_size
Modify: alter system set shared_pool_size=120m;
4) Data dictionary cache: Store the definitions of data files, tables, indexes, columns, users and other data objects in the database The size of and permission information
is determined by shared_pool_size, which cannot be specified separately.
5) Large pool: It is an optional area for some large processes such as Oracle's backup and recovery operations, IO server processes, etc.
6) Java pool: this program Buffers are reserved for Java programs. There is no need to change the default size of the buffer if you do not use a Java program.
7) Stream pool: used by Oracle
streams When released, it can only be used by one process.
PGA includes the following structures:
(1) Sorting area
(2) Cursor status area
(3) Session information area
(4) Stack area
is determined by the parameter: pga_aggregate_target Second, background structures
Several types of processes: user process (User Process), service process (Server Process), background process (Background Processes), other optional processes
User process: generated when the user connects to the database, to request the oracle server connection, a connection must be established first, It will not directly connect to the oracle server.
Server process: generated when an instance is connected and a user session is established. A standalone server or a shared server can generate a
background process: maintain the connection between physical and memory, and manage the reading and writing of the database, recovery and surveillance. The Server Process mainly contacts and communicates with the user process through him, and exchanges data between him and the user process.
On Unix machines, Oracle daemons are relative to operating system processes, that is, an Oracle daemon will start an operating system process.
On a Windows machine, the Oracle background process is relative to the operating system thread, open the task manager, we can only see a process of ORACLE.EXE, but through another tool, we can see the threads contained in this process.
Required process:
PMON --> program monitoring process
SMON --> system monitoring process
DBWn --> database writing process
LGWr --> log writing process
CKPT --> checkpoint process
Optional process:
ARCN archiving process
RECO
Snnn
pnnn
1) DBWR process: This process writes the buffer to the data file and is an Oracle background process responsible for buffer storage management. When a buffer in the buffer is modified, it is marked as "dirty", and the main task of DBWR is to write the "dirty" buffer to disk to keep the buffer "clean". The number of unused buffers decreases as the buffer store's buffers fill the database or get dirty by user processes. When the number of unused buffers drops so low that the user process cannot find the unused buffers when it wants to read blocks from disk into the memory storage, DBWR will manage the buffer storage so that the user process can always get the unused buffers. buffer.
Oracle uses the LRU (LEAST RECENTLY USED) algorithm (least recently used algorithm) to keep data blocks in memory recently used to minimize I/O. DBWR is about to write a dirty buffer to disk in the following situations:
When a server process moves a buffer into the "dirty" table, and the dirty expression reaches a critical length, the server process will notify DBWR to write. The critical length is half the value of the parameter DB-BLOCK-WRITE-BATCH.
When a server process looks up the DB-BLOCK-MAX-SCAN-CNT buffers in the LRU table and finds no unused buffers, it stops the lookup and informs DBWR to write. When a timeout occurs (3 seconds each time), DBWR will notify itself. When a checkpoint occurs, LGWR will notify DBWR. In the first two cases, DBWR will write the blocks in the dirty table to disk, and the number of blocks that can be written each time is specified by the initialization parameter DB-BLOCK-WRITE-BATCH. If there is no buffer with the number of blocks specified by this parameter in the dirty table, DBWR looks for another dirty buffer in the LUR table.
A timeout occurs if DBWR is not active for three seconds. In this case DBWR looks up the LRU table for the specified number of buffers, writing any dirty buffers it finds to disk. Whenever a timeout occurs, DBWR looks for a new buffer group. The number of buffers that are looked up by DBWR at a time is twice the value of the parameter DB-BLOCK-WRITE-BATCH. If the database is idling, DBWR eventually writes the entire buffer store to disk.
When a checkpoint occurs, LGWR specifies that a modification buffer table must be written to disk. DBWR writes the specified buffer to disk.
On some platforms, an instance can have multiple DBWRs. In such an instance, some blocks can be written to one disk and some blocks can be written to other disks. The parameter DB-WRITERS controls the number of DBWR processes.
2. LGWR process: This process writes the log buffer to a log file on the disk. It is an Oracle background process responsible for managing the log buffer. The LGWR process outputs all log entries since the last time it was written to the disk. LGWR outputs:
◆When the user process commits a transaction, a commit record is written.
◆The log buffer is output every three seconds.
◆When 1/3 of the log buffer is full, the log buffer will be output.
◆When DBWR writes the modification buffer to disk, it will output the log buffer.
The LGWR process writes synchronously to the active mirrored online log file group. If a file in a group is deleted or unavailable, LGWR can continue to write to other files in the group.
The log buffer is a circular buffer. After LGWR writes the log entries of the log buffer to the log file, the server process can write new log entries to the log buffer. LGWR is generally fast to write, ensuring that there is always room in the log buffer for new log entries to be written.
Note: Sometimes when more log buffers are needed, LWGR writes out log entries before a transaction commits, and these log entries are only made permanent after a subsequent transaction commits.
ORACLE uses a fast commit mechanism. When the user issues a COMMIT statement, a COMMIT record is immediately put into the log buffer, but the corresponding data buffer changes are delayed until they are written to the data file when it is more efficient. When a transaction commits, it is assigned a system modification number (SCN), which is recorded in the log along with the transaction log entry. Since the SCN is logged, recovery operations can be synchronized when the parallel server option is configured.
3. CKPT process: when the checkpoint occurs, the process modifies the titles of all data files to indicate the checkpoint. Under normal circumstances, this task is performed by LGWR. However, if checkpointing significantly degrades system performance, the CKPT process can be made to run, and the checkpointing work originally performed by the LGWR process is separated and implemented by the CKPT process. For many application situations, the CKPT process is unnecessary. Only when the database has many data files does LGWR noticeably degrade performance when checkpointing to make CKPT run. The CKPT process does not write blocks to disk, that work is done by DBWR. The initialization parameter CHECKPOINT-PROCESS controls the enable or disable of the CKPT process. The default is FALSE, which means it cannot be used.
Due to the inconsistency of the work of LGWR and DBWR in Oracle, Oracle introduced the concept of checkpoint to synchronize the database and ensure the consistency of the database. In Oracle, there are two types of checkpoints: full checkpoints and incremental checkpoints. Below we introduce the functions of these two checkpoints:
1. Complete checkpoint
Before Oracle8i, the checkpoint of the database is a complete checkpoint, and a complete checkpoint will write all the dirty data blocks in the data buffer to the corresponding In the data file, and synchronize the data file header and control file to ensure the consistency of the database. A complete checkpoint will only occur after 8i in the following two cases:
(1) DBA manually executes the alter system checkpoint command;
(2) the database is shut down normally (immediate, transcational, normal).
Since a full checkpoint will write all dirty database blocks, huge IO often affects the performance of the database. Therefore, Oracle has introduced the concept of incremental checkpoints since 8i.
2. Incremental checkpoints
Oracle has introduced the concept of checkpoint queue since 8i, which is used to record the information of all the current dirty data blocks in the database. DBWR writes the dirty data blocks to the data file according to this queue. The checkpoint queue records the information of dirty data blocks in the database in chronological order, and the entries in it contain the RBA (Redo Block Address, which is used to identify the number of the first change of the data block in the redo log during the checkpoint period in the redo log). ) and the data file number and block number of the data block. No matter how many times a data block is changed during a checkpoint, its position in the checkpoint queue remains unchanged, and the checkpoint queue only records its earliest RBA, thereby ensuring that the earliest changed data block can be written as soon as possible. When DBWR writes the dirty data blocks in the checkpoint queue to the data file, the position of the checkpoint should be moved backward accordingly. CKPT will record the position of the checkpoint in the control file every three seconds to indicate the time of Instance Recovery. The log entry for the start of recovery, a concept known as the "heartbeat" of the checkpoint. After the checkpoint position is changed, four parameters are used in Oracle to control the distance between the checkpoint position and the last redo log entry. It should be pointed out here that most people think of these 4 parameters as controlling when the incremental checkpoint occurs. In fact this is wrong, these 4 parameters are used to control the number of entries in the checkpoint queue, not the occurrence of checkpoints.
(1) fast_start_io_target
This parameter is used to indicate the total number of IOs that need to be generated when Instance Recovery occurs in the database, which is estimated by AVGIOTIM of v$filestat. For example, a database needs to be recovered within 10 minutes after Instance Crash occurs. Assuming that the IO of the OS is 500 per second, then the database will generate 500*10*60=30,000 IOs when Instance Recovery occurs, that is, We will be able to set fast_start_io_target to 30000.
(2) fast_start_mttr_target
We can see from the above that fast_start_io_target is troublesome to estimate the checkpoint location. In order to simplify this concept, Oracle has introduced a parameter such as fast_start_mttr_target since 9i, which is used to indicate the time when Instance Recovery occurs in the database, in seconds. We can understand this parameter literally, where mttr is short for mean time to recovery. As in the above example, we can set fast_start_mttr_target to 600. When fast_start_mttr_target is set, the fast_start_io_target parameter will no longer take effect. After 9i, the fast_start_io_target parameter has been abolished by Oracle.
(3) log_checkpoint_timeout
This parameter is used to indicate the time interval between the checkpoint position and the end of the redo log file, in seconds, which is 1800 seconds by default.
(4) log_checkpoint_interval
This parameter indicates the checkpoint position and the number of redo log blocks at the end of the redo log, expressed in OS blocks.
(5) 90% OF SMALLEST REDO LOG
In addition to the above 4 initialization parameters, Oracle actually sets the 90% position in front of the end of the redo log file as the checkpoint position. In each redo log, the positions specified by these parameters may be different, and Oracle will confirm the position closest to the end of the log file as the checkpoint position.
4. SMON process: When the process instance starts, it performs instance recovery and is also responsible for cleaning up temporary segments that are no longer used. In environments with the parallel server option, SMON performs instance recovery on a failed CPU or instance. The SMON process is woken up regularly to check if it is needed, or it can be called by other processes when they find it is needed.
5. PMON process: This process performs process recovery when the user process fails, and is responsible for clearing the internal storage area and releasing the resources used by the process. Example: It wants to reset the state of the active transaction table, release the blockade, and remove the ID of the failed process from the active process table. PMON also periodically checks the status of the scheduler process (DISPATCHER) and the server process, and restarts it if it is dead (excluding intentionally deleted processes).
PMON is woken up regularly to check if it is needed, or it can be called when other processes find it is needed.
6. RECO process: This process is a process used when the distributed option is available to automatically resolve failures in distributed transactions. A node RECO background process automatically connects to other databases that contain pending distributed transactions, and RECO automatically resolves all pending transactions. Any rows corresponding to pending transactions that have been processed will be removed from the pending transactions table in each database.
When a database server's RECO daemon attempts to establish communication with the same remote server, RECO automatically reconnects after a time interval if the remote server is unavailable or if the network connection cannot be established.
The RECO background process only occurs on systems that allow distributed transactions, and the DISTRIBUTED C TRANSACTIONS parameter is greater than 0.
7. ARCH process: This process copies the filled online log files to the specified storage device. The ARCH process only exists when the log is for ARCHIVELOG usage and can be archived automatically.
8. LCKn process: It is used in the environment with parallel server options, and there can be up to 10 processes (LCK0, LCK1..., LCK9) for blocking between instances.
9. Dnnn process (scheduling process): This process allows user processes to share a limited server process (SERVER PROCESS). When there is no scheduling process, each user process requires a dedicated service process (DEDICATEDSERVER PROCESS). For multi-threaded server (MULTI-THREADED SERVER) can support multiple user processes. If there are a large number of users in the system, a multithreaded server can support a large number of users, especially in a client-server environment.
Multiple scheduling processes can be established in a database instance. Establish at least one scheduling process for each network protocol. The database administrator decides the optimal number of schedulers to start according to the limit on the number of connections per process in the operating system, and can add or delete schedulers when the instance is running. Multithreaded servers require SQL*NET version 2 or later. In a multithreaded server configuration, a network receiver process waits for client application connection requests and sends each to a dispatcher process. If the client application cannot be connected to a dispatcher process, the network receiver process will start a dedicated server process. The network receiver process is not part of the Oracle instance, it is part of the network process that handles Oracle. When the instance is started, the network receiver is opened, a communication path is established for the user to connect to Oracle, and then each dispatcher process gives its receiver the address of the dispatcher process for the connection request. When a user process makes a connection request, the network receiver process analyzes the request and decides whether the user can use a scheduler process. If so, the network receiver process returns the address of the scheduler process, after which the user process connects directly to the scheduler process. Some user processes cannot schedule process communication (if using a user from a previous version of SQL*NET), and the network receiver process cannot connect this user to a scheduler process. In this case, the network receiver establishes a dedicated server process that establishes an appropriate connection.