Oracle RBMS Architecture SVG PVG background process
- 3. What is architecture What is oracle What is instance Memory structure Process structure Memory Structure SGA PGA
- 6. Database Buffer Cache The database buffer cache, also called the buffer cache, is the memory area that stores copies of data blocks read from data files. A buffer is a main memory address in which the buffer manager temporarily caches a currently or recently used data block. All users concurrently connected to a database instance share access to the buffer cache.
- 7. Redo Log Buffer The redo log buffer is a circular buffer in the SGA that stores redo entries describing changes made to the database. A redo record is a data structure that contains the information necessary to reconstruct, or redo, changes made to the database by DML or DDL operations. Database recovery applies redo entries to data files to reconstruct lost changes. The database processes copy redo entries from the user memory space to the redo log buffer in the SGA. The redo entries take up continuous, sequential space in the buffer. The background process log writer process (LGWR) writes the redo log buffer to the active online redo log group on
- 8. Shared Pool The shared pool caches various types of program data. For example, the shared pool stores parsed SQL, PL/SQL code, system parameters, and data dictionary information. The shared pool is involved in almost every operation that occurs in the database. For example, if a user executes a SQL statement, then Oracle Database accesses the shared pool.
- 9. Large Pool The large pool is an optional memory area intended for memory allocations that are larger than is appropriate for the shared pool. The Large Pool is an optional portion of the SGA that can be used for large memory allocation, such as backup and restore operations and I/O server processes. It is typically used to improve the performance of these operations by reducing the amount of disk I/O required.
- 10. Java Pool The Java pool is an area of memory that stores all session-specific Java code and data within the Java Virtual Machine (JVM). This memory includes Java objects that are migrated to the Java session space at end-of-call.
- 11. Database Buffer Cache Shared Pool Redo Log Buffer Large Pool Java Pool DBWn CKPT LGWR SMON RECO Optional PMON ARCn Optional SGA Data Files Control Files Archive Log Files Redo Log Files User process Server process PGA
- 13. PGA (Program Global Area) memory specific to an operating process or thread that is not shared by other processes or threads on the system. Because the PGA is process-specific, it is never allocated in the SGA. memory heap that contains session-dependent variables required by a dedicated or shared server process. The server process allocates memory structures that it requires in the PGA. Each server process has a PGA allocated that is a private area for each server Work area for each application.
- 14. Process A client process runs the application or Oracle tool code. An Oracle process is a unit of execution that runs the Oracle database code. In the multithreaded architecture, an Oracle process can be an operating system process or a thread within an operating system process. A background process starts with the database instance and perform maintenance tasks such as performing instance recovery, cleaning up processes, writing redo buffers to disk, and so on. A server process performs work based on a client request.
- 15. Mandatory Background processes Oracle has a collection of processes that are called background processes. These processes are responsible for managing memory, performing I/O operations, and other maintenance activities. Following are some important background processes that are required: Background processes are additional processes used by a multiprocess Oracle database. The background processes perform maintenance tasks required to operate the database and to maximize performance for multiple users. Each background process has a separate task, but works with the other processes.
- 16. Mandatory background processes Process Monitor Process (PMON) Group Process Manager (PMAN) Listener Registration Process (LREG) System Monitor Process (SMON) Database Writer Process (DBW) Log Writer Process (LGWR) Checkpoint Process (CKPT) Manageability Monitor Processes (MMON and MMNL) Recoverer Process (RECO)
- 17. Process Monitor Process (PMON) The process monitor (PMON) monitors the other background processes and performs process recovery when a server or dispatcher process terminates abnormally. PMON is responsible for cleaning up the database buffer cache and freeing resources that the client process was using. For example, PMON resets the status of the active transaction table, releases locks that are no longer required, and removes the process ID from the list of active processes.
- 18. System Monitor Process (SMON) These processes are responsible for performing system-level recovery and maintenance activities. Performing instance recovery, if necessary, at instance startup. In an Oracle RAC database, the SMON process of one database instance can perform instance recovery for a failed instance. Recovering terminated transactions that were skipped during instance recovery because of file-read or tablespace offline errors. SMON recovers the transactions when the tablespace or file is brought back online. Cleaning up unused temporary segments. For example, Oracle Database allocates extents when creating an index. If the operation fails, then SMON cleans up the temporary space. Coalescing contiguous free extents within dictionary-managed tablespaces.
- 19. Database Writer Process (DBWn) The database writer process (DBWn) writes the contents of database buffers to data files. DBWn processes write modified buffers in the database buffer cache to disk (see "Database Buffer Cache"). The DBWn process writes dirty buffers to disk under the following conditions: When a server process cannot find a clean reusable buffer after scanning a threshold number of buffers, it signals DBWn to write. DBWn writes dirty buffers to disk asynchronously if possible while performing other processing. DBWn periodically writes buffers to advance the checkpoint, which is the position in the redo thread from which instance recovery begins (see "Overview of Checkpoints"). The log position of the checkpoint is determined by the oldest dirty buffer in the buffer cache.
- 20. Log Writer Process (LGWR) The log writer process (LGWR) manages the online redo log buffer. LGWR writes one portion of the buffer to the online redo log. By separating the tasks of modifying database buffers, performing scattered writes of dirty buffers to disk, and performing fast sequential writes of redo to disk, the database improves performance. In the following circumstances, LGWR writes all redo entries that have been copied into the buffer since the last time it wrote: A user commits a transaction. An online redo log switch occurs. Three seconds have passed since LGWR last wrote. The redo log buffer is one-third full or contains 1 MB of buffered data. DBW must write modified buffers to disk.
- 21. Checkpoint Process (CKPT) The checkpoint process (CKPT) updates the control file and data file headers with checkpoint information and signals DBW to write blocks to disk.
- 22. Manageability Monitor Processes (MMON and MMNL) The manageability monitor process (MMON) performs many tasks related to the Automatic Workload Repository (AWR). Recoverer Process (RECO) In a distributed database, the recoverer process (RECO) automatically resolves failures in distributed transactions. The RECO process of a node automatically connects to other databases involved in an in-doubt distributed transaction. When RECO reestablishes a connection between the databases, it automatically resolves all in-doubt transactions, removing from each database's pending transaction table any rows that correspond to the resolved transactions.
- 23. Archiver Processes (ARCn) An archiver process (ARCn) copies online redo log files to offline storage after a redo log switch occurs. These processes can also collect transaction redo data and transmit it to standby database destinations. ARCn processes exist only when the database is in ARCHIVELOG mode and automatic archiving is enabled.
- 24. File Structure- Three Basic Oracle Files Control Files Redo Log Files Data Files Provides changes to Parameter File 1 2 3
- 25. Parameter File – the init.ora file Purpose: specifies the configuration information about the database instance. The parameters include: Names and locations of the control files Block size Cache sizes Database name Instance name Domain name Is read each time a database instance is started Has a .ora suffix
- 26. Control Files Purpose: contain a list of all other files that make up the database such as data files and Redo Log files. also contain important information about the contents and operating state of the database. The data includes:- 1. The name of the database 2. Date the database was created 3. Current state of the database: read-only, need-recovery 4. Database status when last closed 5. Interval covered by each archived redo log 6. Backups performed 7. Since this is a critical file you should have more than one control file and they should be on separate disk drives
- 27. Data Files Purpose: contain the actual data stored in the database. contains user data stored in tables + includes indexes, data dictionary. Characteristics: 1. Data files are composed of Oracle blocks, which are in turn composed of operating system blocks 2. Oracle block sizes range from 2 Kb to 32 Kb – average size is 8 Kb 3. Data files belong to only one database and to only one tablespace within that database 4. Data files are the lowest level of granularity between an Oracle database and the operating system 5. Have a .dbf suffix
- 28. Redo Log Files Purpose: store changes made to the database as a result of transaction and internal Oracle activities. Characteristics: 1. Every Oracle 10g database must have at least two redo log groups 2. Oracle 10g keeps track of the Redo Log file by using a redo log sequence number, this number is recorded inside the file as they are used 3. Have a .log suffix
- 30. Logical Storage Structures Oracle Database allocates logical space for all data in the database. The logical units of database space allocation are data blocks, extents, segments, and tablespaces. At a physical level, the data is stored in data files on disk. The data in the data files is stored in operating system blocks.
- 32. Tablespace is used to store related database objects. One tablespace is used to store all of the system tables; another tablespace may be created for all indexes or a tablespace may be created to store all of the tables for a specific application. The idea is to store data that has something in common or has similar characteristics. The database server stores the data in each tablespace in data files with .dbf extensions. Segments are used to organize tablespace data within a tablespace. A segment stores an individual database object like a table or index. Extents are contiguous units of storage, usually disk space, within a segment. Oracle uses extents for performance reasons by storing data that needs to be retrieved in a single disk I/O. An extent is made up of multiple data blocks Data Blocks are the smallest unit of Oracle database storage. Oracle 10g stores 8,192 bytes (8K) in one data block. A data block contains header, directory and row data: 1. Block Header - operating system block address 2. Table Directory - identifies the database table for which the following data belongs 3. Row Directory - identifies the database rows for which the data belongs 4. Row Data - stores the actual row values
- 34. At the finest level of granularity, Oracle Database stores data in data blocks. One logical data block corresponds to a specific number of bytes of physical disk space, for example, 2 KB. Data blocks are the smallest units of storage that Oracle Database can use or allocate. An extent is a set of logically contiguous data blocks allocated for storing a specific type of information.. A segment is a set of extents allocated for a specific database object, such as a table. For example, the data for the employees table is stored in its own data segment, whereas each index for employees is stored in its own index segment. Every database object that consumes storage consists of a single segment. Each segment belongs to one and only one tablespace. Thus, all extents for a segment are stored in the same tablespace. Within a tablespace, a segment can include extents from multiple data files,