The Oracle DBMS Architecture: A Technical Introduction

Transcription

1 BY DANIEL D. KITAY The Oracle DBMS Architecture: A Technical Introduction As more and more database and system administrators support multiple DBMSes, it s important to understand the architecture of the system and its components. This article introduces the reader to the Oracle DBMS. TODAY S database and system administrators must support more and more Management Systems (DBMSes) from different vendors running on various hardware and operating system platforms. One of these DBMSes is the Oracle 7 server. To effectively administer Oracle 7 servers and the databases accessed, it s important to understand the Oracle 7 server architecture. This article examines the Oracle 7 server architecture and its major components. It is intended to benefit new Oracle programmers, DBAs, system administrators and their managers. Although it is impossible to describe all of the features and components of the Oracle 7 server in just one article, the following essential topics are discussed: instance and database startup; instance and application processes; server memory structures; server and database files; and performance monitoring and tuning. INSTANCE AND DATABASE STARTUP As depicted in Figure 1, an Oracle server instance is the combination of server background processes and memory structures that allow database data to be stored, managed and accessed by users. During Oracle server startup, an init.ora configuration file (similar to DB2 s DSNZPARM) is read in and a number of background processes are created that perform specific database and server functions. The process of starting an instance includes the allocation of several memory structures, including the System Global Area (SGA) and Program Global Area (PGA), both of which are discussed later. Typically, during server startup a database is immediately mounted and opened to allow user and application access. Mounting a database is the process of associating a database with the started Oracle server s background processes and allocated memory structures. Although DB2 supports multiple databases accessible from a single subsystem, the Oracle 7 server supports access only to a single database at a time. When a database is mounted, the instance finds and opens its control files. The control files specify the names of the database s data files and redo log files. A database can be mounted in either exclusive or parallel mode. Parallel mode allows an Oracle Parallel (OPS) environment to exist by allowing multiple Oracle servers across multiple machines to mount the same shared database. Opening a mounted database is the process of making the database available for normal database operations. When an instance opens a database, one or more rollback segments are acquired so that the instance can handle rollback information produced by subsequent transaction executions. At this point, any valid user can connect to the database and access or change information. When the database is opened, the online data and redo log files are also opened. An instance can also be started in (or later, dynamically altered to be in) restricted mode so that when the database is open, connections are limited only to those whose user accounts have been granted the RESTRICTED SESSION system privilege Candle Corporation. Reprinted with permission. All rights reserved. International copyright secured.

2 Figure 1: Oracle 7 Architecture:, Memory and Files User (access via MTS) Dnnn SMON PMON RECO Systems Global Area (SGA) Buffer Cache Shared (Snnn) User Process Redo Log Buffer Dedicated A database is sometimes left unmounted, or mounted and unopened, during startup to allow execution of administrative functions that require the database s data to be unavailable to users. INSTANCE AND APPLICATION PROCESSES An Oracle DBMS comprises two types of processes: user and Oracle system. A user or client process is created to execute the program code of an application. It also manages the communication with the Oracle server processes. Oracle system processes are called by other users or Oracle processes to perform functions on behalf of the invoking process. Oracle system processes are divided into two types: server processes and background processes. processes exist to service requests from connected user processes. A server process receives SQL statement requests, checks the shared pool within the SGA for the parsed form of the SQL statement (if it does not exist within the shared pool, it is read in and parsed), checks user access privilege, retrieves data from the actual data file or data that is already cached in the instance s SGA, and makes the data available to the requesting application. In a dedicated server configuration (sometimes called two-task Oracle), each server process handles requests for a single user process. In this type of system, the application process and the Oracle server process frequently execute on different machines. Even when the user is not actively making a database request, the dedicated Shared Pool Shared SQL Areas or Library Cache Dictionary Cache CKPT Files DBWR LCKn (Oracle Parallel ) LGWR Redo Log Files Archive Storage ARCH Control Files server process still exists. These dedicated connections are always required when executing certain Oracle administration functions, such as database startup, shutdown and recovery. In a Multi-Threaded (MTS) configuration, as shown in Figure 2, many user processes can be serviced by a smaller number of shared server processes. This helps reduce process memory utilization and process management overhead. An MTS configuration uses a SQL*Net network listener process to connect user processes to dispatchers, which route client requests to the next available shared server Figure 2: Oracle Multi-Threaded Architecture Listener User processes and application code Dispatcher processes (Dnnn) Request Queue (common to all dispatchers) S Y S T E M S process. The shared server process performs the same function as a dedicated server process, but after servicing each SQL request it is free to service requests from a different user process. Configuration values control the initial and maximum number of shared servers allowed active at one time. Request and response queues are used by the dispatchers and shared servers to communicate SQL requests and to return data results. At startup time, Oracle creates a number of system background processes for each instance to perform system functions: The System Monitor (SMON) performs instance recovery during startup, cleans up temporary segments that are no longer in use, recovers dead transactions skipped during crash and instance recovery because of file-read or offline errors, and coalesces small chunks of contiguous free space into larger blocks of contiguous space for easier allocation by Oracle. The Process Monitor (PMON) performs recovery when a user process fails. PMON cleans up the cache and frees resources that the process was using. PMON also restarts failed dispatcher and shared server processes. The Writer (DBWR) writes modified (dirty) data blocks from the database cache to data files on disk using a least recently used algorithm. Shared (Snnn) Response Queue (one per dispatcher) System Global Area TCP/IP xxxxxxx yyyyyyy Client Workstations February 97 TECHNICAL SUPPORT

3 S Y S T E M S Whenever possible, DBWR writes dirty buffers to disk using a multi-block write mechanism. DBWR manages the buffer cache so that user processes can always find free buffers. The DBWR process is signaled to write dirty buffers to disk under the following conditions: when the dirty list reaches a threshold length defined by the init.ora parameter DB_BLOCK_WRITE_BATCH; when a free buffer has not been found after n buffers have been scanned (where n is defined by DB_BLOCK_MAX_SCAN_CNT in init.ora); when a timeout occurs (every three seconds); when a checkpoint occurs; and when the Log Writer (LGWR) signals DBWR. The LGWR is triggered during several internal events (commit, checkpoint, and log write timeout), as well as when the redo log buffer is one-third full. This process writes the redo log buffer in memory to the redo log file on disk. During each Checkpoint (CKPT), the LGWR updates file headers if a CKPT process is not configured to perform this function. The optional CKPT updates the headers of all data files during checkpoint processing. If the init.ora CHECK- POINT_PROCESS parameter is enabled, this process can improve system performance by freeing the LGWR to concentrate on the redo log buffer. The CKPT process does not write data blocks to disk; this is performed by the DBWR. The Recoverer (RECO) is started when distributed transactions are permitted and the init.ora parameter DISTRIB- UTED_TRANSACTIONS is greater than zero. The Oracle distributed option uses the RECO process to automatically resolve distributed transaction failures. The Archiver (ARCH) copies online redo log files, once they become full, to a specified storage device or location. ARCH is present only when the database is started in ARCHIVELOG mode and automatic archiving is enabled. An Oracle DBMS comprises two types of processes: user and Oracle system. A user or client process is created to execute the program code of an application. It also manages the communication with the Oracle server processes. Oracle system processes are called by other users or Oracle processes to perform functions on behalf of the invoking process. Lock (LCKn) processes are used in conjunction with the Parallel option. Up to 10 LCK processes (LCK0 through LCK9) are used to control inter-instance locking. Dispatcher (Dnnn) processes, used with the MTS configuration, allow user processes to share a limited number of shared server processes. At least one dispatcher process must be created for each network protocol used to communicate with Oracle. Parallel Query server processes are used with the Parallel Query option in Oracle 7.1 or higher. With this option, a query coordinator (QC) intercepts queries, decides if they should be split into multiple smaller queries, and sends them to the pool of available query servers for processing. Query servers are also used for parallel index creation and data loads. The number of query servers automatically increases or decreases (within the upper and lower limits set by the administrator) to accommodate changing workload levels. Snapshot (SNPn) processes are used with the Oracle distributed option to automatically refresh table snapshots. These processes wake-up periodically when snapshots are scheduled to be automatically refreshed. SERVER MEMORY STRUCTURES To operate, each Oracle instance allocates a number of cache areas. As shown in Figure 1, the major memory areas are the SGA, PGA and sort areas. The SGA is a single shared memory area consisting of three main components: Buffer cache, Shared Pool and Redo Log buffer. The size of the SGA is based on various init.ora parameter values including: DB_BLOCK_SIZE, DB_BLOCK_BUFFERS, LOG_BUFFER, and SHARED_POOL_SIZE. The Buffer cache holds the most recently used data from files on disk. It is similar to using a single DB2 Buffer Pool (BP), but without the ability to dynamically alter its size. Buffer cache size is determined at Oracle startup based on the DB_BLOCK_BUF- FERS parameter. Each block size is usually between 2KB and 32KB (in multiples of 2KB), as determined by DB_BLOCK_SIZE. The Shared Pool is similar to DB2 s Environmental Descriptor Manager pool, which contains runtime definitions for SQL statements and other dictionary information. The Shared Pool contains cache areas for parsing and storing SQL and PL/SQL statements (Shared SQL Area); a Data Dictionary cache (row cache) which contains database reference information, similar to DB2 s dictionary database; and, in an MTS configuration, private SQL areas containing binding information and run-time buffers. The SHARED_POOL_SIZE parameter defines the size of the Shared Pool. The Redo Log buffer is an area of the SGA that Oracle uses to record database related changes caused by SQL INSERT, UPDATE, DELETE, CREATE, ALTER, or DROP, and to recreate data or objects during recovery of an executing transaction. It is a circular buffer that contains redo entries containing the information necessary to reconstruct or redo changes made to the database. Redo entries are later copied to the active redo log file on disk. Oracle s logging functions are very similar to DB2 log buffer and online log files. Redo Log buffer size is determined by the LOG_BUF- FER parameter. Oracle also uses rollback segments. These memory areas store pre-update images that can be used to rollback transaction updates and allow access to data as it is being updated (dirty reads).

4 When the MTS is configured, request and response queues and some contents of the PGA are stored within the SGA. Other information that needs to be communicated between processes, such as locking information, is also stored within the SGA. A fixed SGA area stores information about the state of the database and instance for access by background processes. The PGA is memory that contains data and control information for an Oracle instance or application process. Each process has its own PGA; its contents vary depending on whether an MTS configuration is used by a user or application to connect to the Oracle instance. Each process PGA always contains stack space, which is memory used to hold a session s variables, arrays and other information. A PGA without an MTS connection requires additional memory for the user s session, such as private SQL areas. If the connection uses an MTS, the extra memory is allocated to the SGA instead of the PGA. Several initialization parameters affect the size of a PGA, including OPEN_LINKS, DB_FILES and LOG_FILES. On top of physical SGA and PGA memory, some logical memory structures are created. These structures may be shared or private and differ as to when they are allocated and deallocated. Logical memory structures include: User Global Area (UGA), Call Global Area (CGA), Shared Context Areas or Cursors, Cursor Ephemeral Frame, Cursor Work Heap, Cursor Persistent Frame, and connection memory (HGA). For more information on these areas, refer to the article UGA and More Undocumented Features in the bibliography. Finally, sorting requires sort space in memory. A sort area exists in the memory of an Oracle user process that requests a sort. A sort area dynamically grows to accommodate the amount of data to be sorted, within the limits of the SORT_AREA_SIZE value. If Oracle does not need to reference the sort area, it may dynamically reduce its size as determined by the SORT_AREA_RETAINED_SIZE parameter. When needed, Oracle uses temporary segments on disk to contain sort work areas. These temporary segments are dynamically created and deleted on an as needed basis. In Oracle 7.3, permanent segments can be created to contain sort work areas, similar to the permanently allocated sort work tables in DB2. This eliminates the overhead associated with frequently creating and deleting temporary sort segments. In Oracle 7.3, permanent segments can be created to contain sort work areas, similar to the permanently allocated sort work tables in DB2. SERVER AND DATABASE FILES An Oracle instance uses a number of different physical and logical structures to operate. Some of the physical structures used by an Oracle instance are shown in Figure 1: Oracle database files contain database information, including both system and application data. System data files contain the contents of the SYSTEM tablespace, including the data dictionary and the names and locations of all objects within the database. Application data files hold user data that is accessed by SQL statements. Oracle parameter file, init.ora, contains startup parameters to customize the Oracle instance s execution environment. Control files are used to record the names of the database s data files and redo log files as well as other status and configuration information. Online and Archived Redo log files record changes made to data and ensure that no data is lost in the event of an instance failure. An online redo log consists of two or more pre-allocated files that store all changes made to the database as they occur. Archived (offline) redo logs consist of archived online redo log files that become full. The archived redo log is optional based on a database s archiving mode. backup files can be created to support the restoration of damaged data files or control files. Figure 3: Oracle Logical and Physical Structures Tablespace Segment Extents Blocks (index) (temporary) Process trace files can exist for each server and background process. When a process detects an internal error it dumps error information to its trace file. Trace files can also contain SQL tuning information when the initialization parameter SQL_TRACE is set TRUE (although this global setting is expensive) or when a session enables trace logging by using the ALTER SESSION SET SQL_TRACE = TRUE command. An instance s ALERT file contains a chronological log of messages and errors generated by an instance. One or more configuration files on each client and server define SQL*NET communications and enable client/server connections. As shown in Figure 3, an Oracle database contains several logical structures defined on top of a physical data file s user or system data. Within an Oracle database, the logical structures from the highest to lowest level include: tablespaces, segments, extents and data blocks. February 97 TECHNICAL SUPPORT S Y S T E M S Data Files

5 S Y S T E M S A database is divided into one or more logical storage units called tablespaces. A database administrator can create new tablespaces, add data files for tablespaces, set and alter default segment storage settings for segments created in a tablespace and drop tablespaces. Every database contains a tablespace named SYSTEM that is automatically built during database creation. This tablespace contains the data dictionary tables for the entire database. It is similar to the DB2 catalog and dictionary databases. To add more space to a database, data files can be added to one of its existing tablespaces up to the database limit of the total number of files allowed. The next level of logical structures are segments. A segment is a set of extents stored in the same tablespace that have been allocated for a specific type of data structure. For example, each table s data is stored in its own data segment, while each index s data is stored in its own index segment. Both segment types can reside in the same tablespace and physical files, which is very different from DB2 s implementation of separate table- and indexspaces. Segment extents can span one or more files assigned to a tablespace. When the existing extents for a segment are full, Oracle allocates another extent for that segment. Since extents are allocated as needed, segment extents may be non-contiguous. The main segment types are: one data segment per table, snapshot, or snapshot log defined; one index segment per index defined; one or more rollback segments for recording transaction change activity; and one or more temporary segments to contain sort and other types of work areas. The next level of logical database space is called an extent. An extent is a specific number of contiguous data blocks that is allocated for storing a specific type of information. A single extent cannot span a physical file. A data block is the smallest unit of I/O used by an instance. A data block corresponds to a block of physical bytes on disk, equal to the Oracle data block size. This block size can differ from the standard I/O block size of the operating system that executes Oracle; it is usually either 2KB or 4KB. Each data block contains a header, row directory, row data and free space. Oracle 7 has many configuration options and optional features that must be carefully implemented and tuned for you to optimize your system and application performance. PERFORMANCE MONITORING AND TUNING The Oracle server product includes a number of built-in and add-on tools and mechanisms for monitoring the performance of an Oracle instance and tuning performance. These mechanisms are: more than 30 memory resident tables (X$ tables) and the views on them (V$ tables), providing a wealth of performance and configuration information to users and third-party performance monitors, such as Candle s OMEGAMON Monitoring Agents for Oracle. SQL*DBA monitor facilities (or the more graphical Oracle 7.3 replacement, Manager) to display the contents of dynamic performance tables. Oracle scripts for performance monitoring, including UTLBSTAT, UTLESTAT, and UTLLOCKT.SQL for reviewing locking conflicts. an ANALYZE SQL statement that tells Oracle to collect and store tablespace related statistics, similar to DB2 s RUNSTATS utility. a SQL EXPLAIN PLAN facility, similar to DB2 s, that allows you to review access path choices made by Oracle s cost- and rule-based optimizer. a SQL statement tracing facility (SQL_TRACE) that can be enabled globally for all SQL statements (although not recommended because of high overhead) or at the individual session level. Trace records are written to a file that can be read by a translation and reporting utility called TKPROF. Oracle 7.3 provides more extensive tracing and instrumentation facilities that can be controlled and reported on by an additional product called Oracle Trace. ORACLE 7: THE POWER AND COMPLEXITY This article described the major components of the Oracle 7 server to show both the power and the complexity of this database management system. It has many configuration options and optional features that must be carefully implemented and tuned for you to optimize your system and application performance. ts BIBLIOGRAPHY Oracle 7 Concepts, Part No Oracle 7.2 Parallel, Part No. A UGA and More Undocumented Features, Tony Jambu, Select Journal, July Daniel D. Kitay is R&D manager at Candle Corporation s Westlake, Calif., R&D office. He specializes in designing and implementing applications to manage the performance and availability of distributed systems and applications. For the past 13 years Daniel has worked with IMS, VTAM, DB2 for MVS, and more recently, Oracle, Sybase, Lotus Notes and SAP. He can be reached at dan_kitay@candle.com Technical Enterprises, Inc. Reprinted with permission of Technical Support magazine. For subscription information, mbrship@naspa.net or call , Ext. 116.