Database Architecture

Introduction
An Oracle server is a relational database management system (RDBMS), that is, a server component that manages a relational database model. An RDBMS (or a database server) is able to: . Manage large amounts of data in a multi-user environment so that many users can concurrently access the same data . Maintain relationships between data . Provide secure access to data using over a user authorization concept . Recover data automatically to the most recent consistent status after a system failure . Deliver high performance for processing data requests In an SAP system, the only interactive user connecting to the database server should be the database administrator. Application data processing is almost exclusively performed by work processes of SAP instances in the role of database clients.

Terminology

Figure 1: Database Terminology

database An Oracle database is a collection of data, logically treated as a unit. The data is physically stored in one or several files. Oracle manages data in logical units called tablespaces. A database object, such as a table, is always created in a particular tablespace. A tablespace consists of one or more files.

instance As the database is only a passive part of a database server, some processes and memory structures are needed to access the data and manage the database. The combination of Oracle (background) processes and memory buffers is called an Oracle instance. Every running Oracle database is linked to an Oracle instance. Moreover, every Oracle database needs its own instance. Hint: Using Real Application Clusters (RAC), one database is served by two or more instances. SGA Every time an Oracle instance is started, a shared memory region called the System Global Area (SGA) is allocated. The SGA allocated by an Oracle instance can only be accessed by the processes of this instance. This means that each instance has its own SGA. The SGA contains copies of data and control information for the corresponding Oracle instance. When the instance is stopped, the SGA is deallocated. processes Every time an Oracle instance is started, Oracle background processes are started. When an instance shuts down, the processes are stopped. Hint: In a UNIX environment, Oracle processes are visible as operating system processes. On Windows platforms on the other hand, they are implemented as threads, which run within an Oracle operating system process oracle.exe. This means that they do not appear in the operating system process display. system identifier (DBSID) Every database is uniquely identified in the network by its system identifier. On SAP systems, the system identifier must consist of exactly three characters, the first of which must be an uppercase letter, while the other two can be uppercase letters or digits. Because the term system identifier is also used for SAP systems, we consequently distinguish between the database system identifier (referred to as DBSID) and the SAP system identifier (referred to as SAPSID).

Database architecture
Oracle Instance and Database: Architecture Overview

After an Oracle instance is started, a special process, the Listener allows the database clients and the instance to communicate with each other. Note: The listener process is not part of an Oracle instance; it is part of networking processes that work with Oracle. In SAP installations, dedicated servers are used. When a work process makes a request to connect to the database, the listener creates a dedicated server process and establishes an appropriate connection. . The separate server process created on behalf of each work process (generally, for each user process) is called a shadow process. . To handle database requests from several SAP system users, a work process communicates with its corresponding shadow process. . When a work process has lost its connection to the database system, it automatically reconnects after the database server is available again and a database request is to be processed. Oracle background processes perform various tasks required for the database to function properly. Databases are stored in data files on disks. To accelerate read and write access to data, it is cached in the database buffer cache in the SGA. . The Oracle database management system holds the executable SQL statements in the shared SQL area (also called the shared cursor cache), which is part of the shared pool allocated in SGA. Another part of the shared pool called the row cache caches Oracle data dictionary information.

Caching of Data
Databases are stored in data files on hard disks. However, data is never processed on the disks themselves. No matter whether a database client just needs to read some data

or wants to modify it, it is first copied by the associated shadow process from the disk to the database buffer cache in the system global area (if it was not already there).

Figure 3: Oracle Architecture: Caching of Data

Data is always cached if the data is accessed for the first time after an Oracle instance is started. But as all users concurrently connected to the instance share access to the database buffer cache, copies of data read from data files into the buffer cache can be reused by any user. The smallest logical unit that Oracle uses for copying data between data files and the buffer cache, as well as for managing data in the cache, is the data block. . The size of an Oracle data block can generally be chosen during the creation of a database. In SAP installations, however, the block size is always 8 KB. . For performance reasons, the physical allocation unit size on disks where you store Oracle files should also be 8 KB. Oracle always tries to keep the most recently used data blocks in the buffer cache. Depending on the size of the buffer cache, it may sometimes be necessary to overwrite the least recently used data blocks in the buffer cache.

Writing of Modified Data

Figure 4: Oracle Architecture: Writing of Modified Data

Any changes to Oracle data (inserts, updates, and deletions), are always performed in the buffer cache. An Oracle shadow process itself never copies modified data blocks ('dirty blocks') from the buffer cache to the disk. This is the task of a special Oracle background process called the database writer . The database writer process writes dirty blocks to disk in the following situations: . Buffers in the buffer cache that contain dirty blocks (dirty buffers) may not be reused until these blocks have been copied back to disk. When a shadow process needs to copy data from disk to the buffer cache, it first scans the cache for non-modified, reusable buffers. If the number of scanned buffers reaches a certain threshold, the shadow process signals the database writer to start writing some of the modified blocks to disk. The database writer then copies those dirty blocks that are on the list of least recently used blocks (LSU list), thus making them free. . At specific times, all modified buffers in the SGA are written to data files by the database writer. This process is called checkpoint, and checkpoint process (CKPT) triggers the database writer to perform the process. Using the concept of deferred writes rather than immediate writes improves efficiency because in many cases, several changes on the same block are performed before the block is copied to disk. Also, the database writer performs multiblock writes in a batch(ed) style to increase I/O efficiency. Hint: Although one database writer process (DBW0) is sufficient for most systems, additional database writer processes (DBW1 and so on) may be configured in exceptional cases. See SAP Notes 124361 and 191463

Logging of Modifications

Figure 5: Oracle Architecture: Logging of Modifications

Because of deferred writes, a mechanism is needed to prevent data loss and also to avoid data inconsistencies in case of a crash of any system component (disk, Oracle instance, or server). Generally, each RDBMS logs all data changes in a log area, which is written to disk at appropriate times. The log is generally written to disk after the commit of a database transaction so that all data block changes are logged. A database transaction is a logical unit of work for the database server (LUW - logical unit of work), which is always treated as an .atomic. unit, meaning it must either be processed completely or not at all. To achieve data consistency and read consistency, Oracle maintains redo entries for roll forward or redo recovery for example