(Les01 Architecture III process structure) [20180113], les0120180113

(Les01 Architecture III process structure) [20180113], les0120180113
Process Architecture

 

-Using the ghost process: connect to the Oracle DB application or tool-database process-server process: connect to the Oracle instance and start the background process when the user establishes a session: when starting an Oracle instance, start the daemon/application process-network listener-Grid infrastructe daemon dedicated server. For each session, all user processes running database applications are provided by the server processes that execute the Oracle DB server. The shared server does not have to provide a dedicated server process for each connection. The dispatcher directs multiple incoming Network Session requests to the Shared Server process pool. The sharing server process provides services for all client requests. Server process-perform syntax analysis on the SQL statements sent through the application and run the statement-read the necessary data blocks from the data files on the disk to the SGA shared database buffer (if these data blocks are not currently in SGA) -The returned results allow the application to process the information background process. The processes used by the Oracle DB system are collectively referred to as "background processes". An Oracle DB instance can have multiple background processes. Common background processes in non-RAC and non-ASM environments-DBWn database write process-LGWR log write process-CKPT Checkpoint Process-SMON system monitoring process-PMON process monitoring process-RECO restorer process- CJQ0 Job Queue coordinating Program-Jnnn job subordinate process-ARCn archiving process-more advanced configuration of QMNn queue monitoring process (such as RAC) there will be other background processes. For details about background processes, see V $ BGPROCESS view. Some background processes are automatically created when the instance is started, while others are created as needed. Other process structures are not unique to a single database, but can be shared among multiple databases on the same server. Grid Infrastructure processes and Network processes belong to this category. The Grid Infrastructure processes on Liunx and Unix systems include-ohasd: The Oracle High Availability service daemon, which is responsible for starting the Oracle Clusterware process. -Ocssd: the cluster synchronization service daemon-diskmon: disk monitoring daemon, which monitors the input and output of HP Oracle Exadata Storage Server-cssdagent: start, stop, and check the status of the CSS daemon ocssd-orarootagent: a dedicated Oracle proxy process that helps you manage the resources (such as the network) owned by root users) DBWn Data Writing Process Parameter: db_writer_processes writes the modified buffer (dirty data) in the cache of the database buffer to the disk in two ways: -asynchronous execution of other processing-promotes the checkpoint database write process (DBWn) to write dirty data in the buffer zone to the data file. For most systems, a database write process (DBWn) is sufficient, but if the system needs to modify data frequently, you can also configure additional processes (DBW1 to DBW9 or DBWa to DBWz) to improve the write performance. These additional processes do not work in a single processor system. When a buffer data in the cache of the database buffer is modified, the system marks it as dirty data and adds it to the header of the checkpoint queue in the sequence of SCN. Therefore, this order is consistent with the order in which the redo entries in these changed buffers are written into the redo log. When the number of available buffers in the buffer cache is lower than a certain internal threshold value, DBWn writes infrequently used buffers to data files. The write sequence starts at the end of the LRU list, so that processes can replace them when they need a buffer. DBWn also writes data from the end of the checkpoint queue to protect the checkpoint from moving forward. SGA has a memory structure that stores the redo byte address (RBA) at the position of the redo stream. When the instance fails to be sent, the redo byte address (RBA) is restored from this position. This structure acts as a pointer to redo, And the CKPT process writes the control file every three seconds. Because DBWn writes dirty data in the sequence of SCN and retries are executed in the sequence of SCN, Every time DBWn writes dirty data from the LRU list, the pointer maintained in the SGA memory structure is also moved forward, so that the instance can be restored (if needed) from the approximate correct position to read and redo, and avoid unnecessary I/O. This is called "incremental checkpoint ". The LRU algorithm stores frequently accessed blocks in the buffer cache to minimize disk reading. You can use the cache option for the table to help extend the retention time of the block in the memory. The DB_WRITER_PROCESSES initialization parameter specifies the number of DBWn processes. The maximum number of DBWn processes is 36. If the number of processes is not specified during startup, Oracle DB determines the number of CPU and processor groups if DB_WRITER_PROCESSES is set. DBWn database write process trigger condition:-generate checkpoint CKPT-dirty data buffer reaches threshold default 10%-scan the entire data buffer without idle data buffer contains dirty and not dirty, the system preferentially writes the dirty data list and then writes the undirty block-timeout, if DBWn has nothing to do, it will be awakened once every three seconds to go to the inspection and write, not necessarily-table-level truncate or drop will also trigger Data Writing-Modify the read-only-do the offline) -The hot backup begin backup command in all cases, DBWn executes batch (multiple) write operations to improve efficiency. The number of write blocks varies with the operating system. The LGWR log writing process writes the redo log buffer to the redo log file on the disk. The redo log buffer is a circular buffer. When LGWR writes the redo entries in the redo log buffer to the redo log file, the server process can then copy new entries, overwrite the entries written to the disk in the redo log buffer. The write speed of LGWR is usually fast enough to ensure that there is always space in the buffer zone for new entries, even if the access to redo logs is large. LGWR writes a continuous part of the buffer to the disk. LGWR log write process trigger condition:-when the user process commits transaction processing-when the 1/3 of the redo log buffer is full-The DBWn process writes the modified buffer to the disk (if needed) previous-redo entries with a redo buffer size of 1 MB-The CKPT Checkpoint Process "checkpoint" is a data structure every 3 seconds, it defines the system change number (SCN) in the redo thread of the database ). Checkpoints are recorded in the control file and each data file header. They are key elements of recovery operations. The CKPT Checkpoint Process is triggered when DBWn writes dirty data in the high-speed buffer to a data file. It verifies the header of all related data files to be written, the checkpoint number, redo log serial number, archived log name, and minimum/maximum SCN number are also written into the control file. CKPT checkpoint Process triggering condition:-The log_checkpoint_timeoute threshold value reaches-log_checkpoint_interval * Operating system block size-redo log switch & alter system checkpoint, log switching and explicit generation of checkpoint-Hot Standby begin backup-tablespace offline & read only, shutdown immediate and direct read SMON system monitoring process-resume upon instance startup. Execute the rollback. Write the data that has been written to the redo log file but has not been written to the data file (scn number to identify submitted records), open the database, and roll back uncommitted transactions. -Clear unused temporary segments. Reclaim or merge the free zones connected to data files and release temporary segments. PMON process monitoring process-Execute Process recovery when the user process fails-CLEAR database buffer cache-release resources used by the user process-monitoring session, check whether Idle session times out-dynamically register the Database Service in the listener

 

RECO) -for Distributed Database Configuration-when a distributed transaction processing problem occurs, it automatically connects to other involved databases-automatically solves all problematic transactions-deletes all rows of the problematic transactions (archive process)) when the archive mode is enabled for the database, alter database archivelog;-after switching logs, copy the redo log file to the specified storage path-collect transaction and redo data, and transmit the data to the standby target location. The target location is log_archive_dest_1 ~ 31 (11g), first 1 ~ 10 mainly stores the local path (or Service name), 11 ~ 30. The local path cannot be stored for the Service. The maximum number of control parameters for the ARCn archive process: LOG_ARCHIVE_MAX_PROCESSES https://docs.oracle.com/cd/E11882_01/server.112/e25494/archredo.htm#ADMIN00801 Jnnn (job-dependent process) & CJQ0 (Job Queue Coordinator) they can be seen as a scheduler service, PL/SQL statements or processes on Oracle database instances. -Jnnn job subordinate processes (or Job Queue processes) are dynamically managed. -The CJQ0 JOB Queue Coordinator regularly selects and runs the Jnnn JOB from the JOB $ table-the CJQ0 process dynamically generates the JOB slave process (J000-J999) -The Jnnn process is executed by a job selected by the CJQ0 process. These processes run a job at a time-after the process is completed, it polls more jobs ). If no job is scheduled to be executed, it goes to sleep state and regularly wakes up other jobs from it. If the process does not find a new job, it is aborted after the preset interval. The maximum number of Jnnn processes at the same time: job_queue_processes processes are different from those of other Oracle database background processes. This process failure will not cause instance failure. The QMNn (queue monitoring process) QMNn queue monitoring process is an optional background process of Oracle Streams Advanced Queuing, used to monitor message queues. -A maximum of 10 QMNn queue monitoring processes can be configured. These processes are different from other Oracle database background processes. Failure of these processes does not cause instance failure.

 

Reference: https://docs.oracle.com/cd/E11882_01/server.112/e40540/process.htm#CNCPT9840