Oracle Architecture

Primary Architecture Components

The figure shown above details the Oracle architecture.

1

Oracle server: An Oracle server includes an Oracle Instance and an Oracle database.

Oracle instance:

An Oracle Instance consists of two different sets of components:

1. Memory structures2. Background processes

● The First component set includes the memory structures that comprise the Oracle instance. ○ When an instance starts up, a memory structure called the System Global Area

(SGA) is allocated. ○ At this point the background processes also start.

● The Second component set is the set of background processes (PMON, SMON, RECO, DBW0, LGWR, CKPT, D000 and others).

○ Each background process is a computer program.

○ These processes perform input/output and monitor, other Oracle processes to provide good performance and database reliability.

● An Oracle Instance provides access to one and only one Oracle database. Oracle database:

An Oracle database consists of files.

● Sometimes these are referred to as operating system files, but they are actually database files that store the database information that a firm or organization needs in order to operate.

● The redo log files are used to recover the database in the event of application program failures, instance failures and other minor failures.

● The archived redo log files are used to recover the database if a disk fails. ● Other files not shown in the figure include:

○ The required parameter file that is used to specify parameters for configuring an Oracle instance when it starts up.

○ The optional password file authenticates special users of the database – these are termed privileged users and include database administrators.

○ Alert and Trace Log Files – these files store information about errors and actions taken that affect the configuration of the database.

2

Oracle instance

Memory Structure

The memory structures include two areas of memory: ● System Global Area (SGA) – this is allocated when an Oracle Instance starts up.● Program Global Area (PGA) – this is allocated when a Server Process starts up.

System Global Area

The SGA is an area in memory that stores information shared by all database processes and by all users of the database (sometimes it is called the Shared Global Area).

○ This information includes both organizational data and control information used by the Oracle Server.

○ The SGA is allocated in memory and virtual memory. ○ The size of the SGA can be established by a DBA by assigning a value to the parameter

SGA_MAX_SIZE in the parameter file—this is an optional parameter.

The SGA is allocated when an Oracle instance (database) is started up based on values specified in the initialization parameter file (either PFILE or SPFILE).

The SGA has the following mandatory memory structures:● Shared Pool – includes two components:

○ Library Cache○ Data Dictionary Cache

3

● Database Buffer Cache● Redo Log Buffer● Other structures (for example, lock and latch management, statistical data)

Additional optional memory structures in the SGA include:● Large Pool ● Java Pool● Streams Pool

The SHOW SGA SQL command will show you the SGA memory allocations. In order to execute SHOW SGA you must be connected with the special privilege SYSDBA (which is only available to user accounts that are members of the DBA Linux group).

SQL> connect / as sysdbaConnected.SQL> show sga

Total System Global Area 1610612736 bytesFixed Size 2084296 bytesVariable Size 385876536 bytesDatabase Buffers 1207959552 bytesRedo Buffers 14692352 bytes

Oracle 8i and earlier versions of the Oracle Server used a Static SGA. This meant that if modifications to memory management were required, the database had to be shutdown, modifications were made to the init.ora parameter file, and then the database had to be restarted.

Oracle 9i and 10g use a Dynamic SGA. Memory configurations for the system global area can be made without shutting down the database instance. The advantage is obvious. This allows the DBA to resize the Database Buffer Cache and Shared Pool dynamically.

Several initialization parameters are set that affect the amount of random access memory dedicated to the SGA of an Oracle Instance. These are:

● SGA_MAX_SIZE: This optional parameter is used to set a limit on the amount of virtual memory allocated to the SGA – a typical setting might be 1 GB; however, if the value for SGA_MAX_SIZE in the initialization parameter file or server parameter file is less than the sum the memory allocated for all components, either explicitly in the parameter file or by default, at the time the instance is initialized, then the database ignores the setting for SGA_MAX_SIZE.

● DB_CACHE_SIZE: This optional parameter is used to tune the amount memory allocated to the Database Buffer Cache in standard database blocks. Block sizes vary among operating systems. The DBORCL database uses 8 KB blocks. The total blocks in the cache defaults to 48 MB on LINUX/UNIX and 52 MB on Windows operating systems.

● LOG_BUFFER: This optional parameter specifies the number of bytes allocated for the Redo Log Buffer.

● SHARED_POOL_SIZE: This optional parameter specifies the number of bytes of memory allocated to shared SQL and PL/SQL. The default is 16 MB. If the operating system is based on a 64 bit configuration, then the default size is 64 MB.

4

● LARGE_POOL_SIZE: This is an optional memory object – the size of the Large Pool defaults to zero. If the init.ora parameter PARALLEL_AUTOMATIC_TUNING is set to TRUE, then the default size is automatically calculated.

● JAVA_POOL_SIZE: This is another optional memory object. The default is 24 MB of memory.

The size of the SGA cannot exceed the parameter SGA_MAX_SIZE minus the combination of the size of the additional parameters, DB_CACHE_SIZE, LOG_BUFFER, SHARED_POOL_SIZE, LARGE_POOL_SIZE, and JAVA_POOL_SIZE.

Memory is allocated to the SGA as contiguous virtual memory in units termed granules. Granule size depends on the estimated total size of the SGA, which as was noted above, depends on the SGA_MAX_SIZE parameter. Granules are sized as follows:● If the SGA is less than 128 MB in total, each granule is 4 MB.● If the SGA is greater than 128 MB in total, each granule is 16 MB.

Granules are assigned to the Database Buffer Cache and Shared Pool, and these two memory components can dynamically grow and shrink. Using contiguous memory improves system performance. The actual number of granules assigned to one of these memory components can be determined by querying the database view named V$BUFFER_POOL.

Granules are allocated when the Oracle server starts a database instance in order to provide memory addressing space to meet the SGA_MAX_SIZE parameter. The minimum is 3 granules: one each for the fixed SGA, Database Buffer Cache, and Shared Pool. In practice, you'll find the SGA is allocated much more memory than this. The SELECT statement shown below shows a current_size of 1,152 granules.

SELECT name, block_size, current_size, prev_size, prev_buffersFROM v$buffer_pool; NAME BLOCK_SIZE CURRENT_SIZE PREV_SIZE PREV_BUFFERS-------------------- ---------- ------------ ---------- ------------DEFAULT 8192 1152 0 0

For additional information on the dynamic SGA sizing, enroll in Oracle's Oracle10g Database Performance Tuning course.

5

Shared Pool

The Shared Pool is a memory structure that is shared by all system users. It consists of both fixed and variable structures. The variable component grows and shrinks depending on the demands placed on memory size by system users and application programs.

Memory can be allocated to the Shared Pool by the parameter SHARED_POOL_SIZE in the parameter file. You can alter the size of the shared pool dynamically with the ALTER SYSTEM SET command. An example command is shown in the figure below. You must keep in mind that the total memory allocated to the SGA is set by the SGA_TARGET parameter (and may also be limited by the SGA_MAX_SIZE if it is set), and since the Shared Pool is part of the SGA, you cannot exceed the maximum size of the SGA.

The Shared Pool stores the most recently executed SQL statements and used data definitions. This is because some system users and application programs will tend to execute the same SQL statements often. Saving this information in memory can improve system performance.

The Shared Pool includes the Library Cache and Data Dictionary Cache.

Library Cache

Memory is allocated to the Library Cache whenever an SQL statement is parsed or a program unit is called. This enables storage of the most recently used SQL and PL/SQL statements.

If the Library Cache is too small, the Library Cache must purge statement definitions in order to have space to load new SQL and PL/SQL statements. Actual management of this memory structure is through a Least-Recently-Used (LRU) algorithm. This means that the SQL and PL/SQL statements that are oldest and least recently used are purged when more storage space is needed.

The Library Cache is composed of two memory subcomponents:

6

● Shared SQL : This stores/shares the execution plan and parse tree for SQL statements. If a system user executes an identical statement, then the statement does not have to be parsed again in order to execute the statement.

● Shared PL/SQL Procedures and Packages : This stores/shares the most recently used PL/SQL statements such as functions, packages, and triggers.

Data Dictionary Cache

The Data Dictionary Cache is a memory structure that caches data dictionary information that has been recently used. This includes user account information, datafile names, table descriptions, user privileges, and other information.

The database server manages the size of the Data Dictionary Cache internally and the size depends on the size of the Shared Pool in which the Data Dictionary Cache resides. If the size is too small, then the data dictionary tables that reside on disk must be queried often for information and this will slow down performance.

Database Buffer Cache

The Database Buffer Cache is a fairly large memory object that stores the actual data blocks that are retrieved from datafiles by system queries and other data manipulation language commands.

A query causes a Server Process to first look in the Database Buffer Cache to determine if the requested information happens to already be located in memory – thus the information would not need to be retrieved from disk and this would speed up performance. If the information is not in the Database Buffer Cache, the Server Process retrieves the information from disk and stores it to the cache.

Keep in mind that information read from disk is read a block at a time, not a row at a time, because a database block is the smallest addressable storage space on disk.

Database blocks are kept in the Database Buffer Cache according to a Least Recently Used (LRU) algorithm and are aged out of memory if a buffer cache block is not used in order to provide space for the insertion of newly needed database blocks.

The buffers in the cache are organized in two lists: ● the write list and,● the least recently used (LRU) list.

The write list holds dirty buffers – these are buffers that hold that data that has been modified, but the blocks have not been written back to disk.

The LRU list holds free buffers, pinned buffers, and dirty buffers that have not yet been moved to the write list. Free buffers do not contain any useful data and are available for use. Pinned buffers are currently being accessed.When an Oracle process accesses a buffer, the process moves the buffer to the most recently used (MRU) end of the LRU list – this causes dirty buffers to age toward the LRU end of the LRU list.

7

When an Oracle user process needs a data row, it searches for the data in the database buffer cache because memory can be searched more quickly than hard disk can be accessed. If the data row is already in the cache (a cache hit), the process reads the data from memory; otherwise a cache miss occurs and data must be read from hard disk into the database buffer cache.

Before reading a data block into the cache, the process must first find a free buffer. The process searches the LRU list, starting at the LRU end of the list. The search continues until a free buffer is found or until the search reaches the threshold limit of buffers.

Each time the user process finds a dirty buffer as it searches the LRU, that buffer is moved to the write list and the search for a free buffer continues.

When the process finds a free buffer, it reads the data block from disk into the buffer and moves the buffer to the MRU end of the LRU list.

If an Oracle user process searches the threshold limit of buffers without finding a free buffer, the process stops searching the LRU list and signals the DBW0 background process to write some of the dirty buffers to disk. This frees up some buffers.

The block size for a database is set when a database is created and is determined by the init.ora parameter file parameter named DB_BLOCK_SIZE. Typical block sizes are 2KB, 4KB, 8KB, 16KB, and 32KB. The size of blocks in the Database Buffer Cache matches the block size for the database. The DBORCL database uses a 8KB block size.

Because tablespaces that store oracle tables can use different (non-standard) block sizes, there can be more than one Database Buffer Cache allocated to match block sizes in the cache with the block sizes in the non-standard tablespaces.

The size of the Database Buffer Caches can be controlled by the parameters DB_CACHE_SIZE and DB_nK_CACHE_SIZE to dynamically change the memory allocated to the caches without restarting the Oracle instance.

You can dynamically change the size of the Database Buffer Cache with the ALTER SYSTEM command like the one shown here:

ALTER SYSTEM SET DB_CACHE_SIZE = 96M;

You can have the Oracle Server gather statistics about the Database Buffer Cache to help you size it to achieve an optimal workload for the memory allocation. This information is displayed from the V$DB_CACHE_ADVICE view. In order for statistics to be gathered, you can dynamically alter the system by using the ALTER SYSTEM SET DB_CACHE_ADVICE (OFF, ON, READY) command. However, gathering statistics on system performance always incurs some overhead that will slow down system performance.

SQL> ALTER SYSTEM SET db_cache_advice = ON;

System altered.

SQL> DESC V$DB_cache_advice; Name Null? Type ----------------------------------------- -------- ------------- ID NUMBER

8

NAME VARCHAR2(20) BLOCK_SIZE NUMBER ADVICE_STATUS VARCHAR2(3) SIZE_FOR_ESTIMATE NUMBER SIZE_FACTOR NUMBER BUFFERS_FOR_ESTIMATE NUMBER ESTD_PHYSICAL_READ_FACTOR NUMBER ESTD_PHYSICAL_READS NUMBER ESTD_PHYSICAL_READ_TIME NUMBER ESTD_PCT_OF_DB_TIME_FOR_READS NUMBER ESTD_CLUSTER_READS NUMBER ESTD_CLUSTER_READ_TIME NUMBER

SQL> SELECT name, block_size, advice_status FROM v$db_cache_advice;

NAME BLOCK_SIZE ADV-------------------- ---------- ---DEFAULT 8192 ON<more rows will display>21 rows selected.

SQL> ALTER SYSTEM SET db_cache_advice = OFF;

System altered.

KEEP Buffer Pool

This pool retains blocks in memory (data from tables) that are likely to be reused throughout daily processing. An example might be a table containing user names and passwords or a validation table of some type.

The DB_KEEP_CACHE_SIZE parameter sizes the KEEP Buffer Pool.

RECYCLE Buffer Pool

This pool is used to store table data that is unlikely to be reused throughout daily processing – thus the data is quickly recycled.

The DB_RECYCLE_CACHE_SIZE parameter sizes the RECYCLE Buffer Pool.

9

Redo Log Buffer

The Redo Log Buffer memory object stores images of all changes made to database blocks. As you know, database blocks typically store several table rows of organizational data. This means that if a single column value from one row in a block is changed, the image is stored. Changes include INSERT, UPDATE, DELETE, CREATE, ALTER, or DROP.

Think of the Redo Log Buffer as a circular buffer that is reused over and over. As the buffer fills up, copies of the images are stored to the Redo Log Files that are covered in more detail in a later module.

Large Pool

The Large Pool is an optional memory structure that primarily relieves the memory burden placed on the Shared Pool. The Large Pool is used for the following tasks if it is allocated:

● Allocating space for session memory requirements from the User Global Area (part of the Server Process) where a Shared Server is in use.

● Transactions that interact with more than one database, e.g., a distributed database scenario.

● Backup and restore operations by the Recovery Manager (RMAN) process.○ RMAN uses this only if the BACKUP_DISK_IO = n and BACKUP_TAPE_IO_SLAVE

= TRUE parameters are set. ○ If the Large Pool is too small, memory allocation for backup will fail and memory will

be allocated from the Shared Pool.● Parallel execution message buffers for parallel server operations. The

PARALLEL_AUTOMATIC_TUNING = TRUE parameter must be set.

The Large Pool size is set with the LARGE_POOL_SIZE parameter – this is not a dynamic parameter. It does not use an LRU list to manage memory.

Java Pool

The Java Pool is an optional memory object, but is required if the database has Oracle Java installed and in use for Oracle JVM (Java Virtual Machine). The size is set with the JAVA_POOL_SIZE parameter that defaults to 24MB.

The Java Pool is used for memory allocation to parse Java commands.

Storing Java code and data in the Java Pool is analogous to SQL and PL/SQL code cached in the Shared Pool.

Streams Pool

This cache is new to Oracle 10g. It is sized with the parameter STREAMS_POOL_SIZE.

10

This pool stores data and control structures to support the Oracle Streams feature of Oracle Enterprise Edition. Oracle Steams manages sharing of data and events in a distributed environment.

If STEAMS_POOL_SIZE is not set or is zero, memory for Oracle Streams operations is allocated from up to 10% of the Shared Pool memory.

Automatic Shared Memory Management (ASSM)

Prior to Oracle 10G, a DBA had to manually specify SGA Component sizes through the initialization parameters, such as SHARED_POOL_SIZE, DB_CACHE_SIZE, JAVA_POOL_SIZE, and LARGE_POOL_SIZE parameters.

Automatic Shared Memory Management enables a DBA to specify the total SGA memory available through the SGA_TARGET initialization parameter. The Oracle Database automatically distributes this memory among various subcomponents to ensure most effective memory utilization.

The DBORCL database SGA_TARGET is set in the initDBORCL.ora file:

sga_target=1610612736

With automatic SGA memory management, the different SGA components are flexibly sized to adapt to the SGA available.

Setting a single parameter simplifies the administration task – the DBA only specifies the amount of SGA memory available to an instance – the DBA can forget about the sizes of individual components. No out of memory errors are generated unless the system has actually run out of memory. No manual tuning effort is needed.

The SGA_TARGET initialization parameter reflects the total size of the SGA and includes memory for the following components:● Fixed SGA and other internal allocations needed by the Oracle Database instance● The log buffer● The shared pool● The Java pool● The buffer cache

If SGA_TARGET is set to a value greater than SGA_MAX_SIZE at startup, then the SGA_MAX_SIZE value is bumped up to accomodate SGA_TARGET. After startup, SGA_TARGET can be decreased or increased dynamically. However, it cannot exceed the value of SGA_MAX_SIZE that was computed at startup.

When you set a value for SGA_TARGET, Oracle Database 10g automatically sizes the most commonly configured components, including:● The shared pool (for SQL and PL/SQL execution)● The Java pool (for Java execution state)● The large pool (for large allocations such as RMAN backup buffers)● The buffer cache

11

There are a few SGA components whose sizes are not automatically adjusted. The DBA must specify the sizes of these components explicitly, if they are needed by an application. Such components are:● Keep/Recycle buffer caches (controlled by DB_KEEP_CACHE_SIZE and

DB_RECYCLE_CACHE_SIZE)● Additional buffer caches for non-standard block sizes (controlled by DB_nK_CACHE_SIZE,

n = {2, 4, 8, 16, 32})● Streams Pool (controlled by the new parameter STREAMS_POOL_SIZE)

Fixed SGA

The fixed SGA is a component of the SGA that varies in size from platform to platform andfrom release to release. It is “compiled” into the Oracle binary itself at installation time (hencethe name “fixed”). The fixed SGA contains a set of variables that point to the other compo-nents of the SGA, and variables that contain the values of various parameters. The size of thefixed SGA is something with which we have no control over, and it is generally very small.Think of this area as a “bootstrap” section of the SGA—something Oracle uses internally tofind the other bits and pieces of the SGA.

Program Global Area

There are two ways to manage memory of the PGA:

Manual PGA memory management, where you tell Oracle how much memory is itallowed to use to sort and hash any time it needs to sort or hash in a specific process

Automatic PGA memory management, where you tell Oracle how much memory itshould attempt to use systemwide

12

The PGA is memory specific to an operating process. The server process allocates memory structures that it requires in the PGA. PGA memory management is controlled by the database initialization parameter WORKAREA_SIZE_POLICY. This initialization parameter defaults to AUTO, for automatic PGA memory management.

The Program Global Area is also termed the Process Global Area (PGA) and is a part of memory allocated that is outside of the Oracle Instance. The PGA stores data and control information for a single Server Process or a single Background Process. It is allocated when a process is created and the memory is scavenged by the operating system when the process terminates. This is NOT a shared part of memory – one PGA to each process only.

The content of the PGA

The PGA is subdivided into different areas, each with a different purpose. Figure14–4 shows the possible contents of the PGA for a dedicated server session. Not all of the PGA areas will exist in every case.

Private SQL Area

A private SQL area holds information about a parsed SQL statement and other session-specific information for processing. When a server process executes SQL or PL/SQL code, the process uses the private SQL area to store bind variable values, query execution state information, and query execution work areas.

A user session issuing SQL statements has a Private SQL Area that may be associated with a Shared SQL Area if the same SQL statement is being executed by more than one system user. (In Shared Server ) Multiple private SQL areas in the same or different sessions can point to a single execution plan in the SGA . For example, 20 executions of SELECT * FROM employees in one session and 10 executions of the same query in a different session can share the same plan.

13

This often happens in OLTP environments where many users are executing and using the same application program.

○ Dedicated Server environment – the Private SQL Area is located in the Program Global Area.

○ Shared Server environment – the Private SQL Area is located in the System Global Area.

A cursor is a name or handle to a specific private SQL area. As shown in Figure14–5, you can think of a cursor as a pointer on the client side and as a state on the server side. Because cursors are closely associated with private SQL areas, the terms are sometimes used interchangeably.

A private SQL area is divided into the following areas:

The run-time area

This area contains query execution state information. For example, the run-time area tracks the number of rows retrieved so far in a full table scan. Oracle Database creates the run-time area as the first step of an execute request. For DML statements, the run-time area is freed when the SQL statement is closed.

The persistent area

This area contains bind variable values. A bind variable value is supplied to a SQL statement at run time when the statement is executed. The persistent area is freed only when the cursor is closed.

SQL Work Area

A SQL work area is a private allocation of PGA memory used for memory-intensive operations. For example, a sort operator uses the sort area to sort a set of rows. Similarly, a hash join operator uses a hash area to build a hash table from its left input, whereas a bitmap merge uses the bitmap merge area to merge data retrieves from scans of multiple bitmap indexes.

Oracle requires room to perform sort operations when restricted joins, index builds and reports are executed. Preferably, this space should be memory space. If the size of a sort is larger than the memory space available, then the sort is done on disk in the users temporary tablespace.

SORT_AREA_SIZE: The total amount of RAM that will be used to sort information before swapping out to disk.

14

SORT_AREA_RETAINED_SIZE: The amount of memory that will be used to hold sorted data after the sort is complete. That is, if SORT_AREA_SIZE was 512KB and SORT_AREA_RETAINED_SIZE was 256KB, then your server process would use up to 512KB of memory to sort data during the initial processing of the query. When the sort was complete, the sorting area would be “shrunk” down to 256KB, and any sorted data that did not fit in that 256KB would be written out to the temporary tablespace.

HASH_AREA_SIZE: The amount of memory your server process would use to store hash tables in memory. These structures are used during a hash join, typically when joining a large set with another set. The smaller of the two sets would be hashed into memory and anything that didn’t fit in the hash area region of memory would be stored in the temporary tablespace by the join key.

Automated PGA Memory Management

The database automatically tunes work area sizes when automatic PGA memory management is enabled.

Oracle 9i and later versions enable automatic sizing of the SQL Work Areas by setting the WORKAREA_SIZE_POLICY = AUTO parameter (this is the default!) and PGA_AGGREGATE_TARGET = n (where n is some amount of memory established by the DBA). However, the DBA can let Oracle 10g determine the appropriate amount of memory.

Oracle 8i and earlier required the DBA Manully to set the following parameters to control SQL Work Area memory allocations:

■ SORT_AREA_SIZE.■ HASH_AREA_SIZE.■ BITMAP_MERGE_AREA_SIZE.■ CREATE_BITMAP_AREA_SIZE.

Session Memory:

Memory that holds session variables and other session information.

Software Code Area

Software code areas store Oracle executable files running as part of the Oracle instance.

These code areas are static in nature and are located in privileged memory that is separate from other user programs.The code can be installed sharable when multiple Oracle instances execute on the same server with the same software release level.

User Global Area (UGA)

15

The UGA is session memory, which is memory allocated for session variables, such as logon information, and other information required by a database session. Essentially, the UGA stores the session state. Figure14–2 depicts the UGA.

If a session loads a PL/SQL package into memory, then the UGA contains the package state, which is the set of values stored in all the package variables at a specific time (see "PL/SQL Packages" on page8-6). The package state changes when a package subprogram changes the variables. By default, the package variables are unique to and persist for the life of the session.

The OLAP page pool is also stored in the UGA. This pool manages OLAP data pages, which are equivalent to data blocks. The page pool is allocated at the start of an OLAP session and released at the end of the session. An OLAP session opens automatically whenever a user queries a dimensional object such as a cube.

The UGA must be available to a database session for the life of the session. For this reason, the UGA cannot be stored in the PGA when using a shared server connection because the PGA is specific to a single process. Therefore, the UGA is stored in the SGA when using shared server connections, enabling any shared server process access to it. When using a dedicated server connection, the UGA is stored in the PGA.

Background Processes

Background Process is a program.Each background process is meant for a specific purpose and its role is well defined. Not all background processes are mandatory for an instance. Some are mandatory and some are optional. Mandatory background processes are DBWn, LGWR, CKPT, SMON, PMON, and RECO. All other processes are optional, will be invoked if that particular feature is activated.

16

Background processes are visible as separate operating system processes in Unix/Linux. In Windows, these run as separate threads within the same service. Any issues related to background processes should be monitored and analyzed from the trace files generated and the alert log.

Background processes are started automatically when the instance is started.

To findout background processes from database:SQL> select SID,PROGRAM from v$session where TYPE='BACKGROUND';

To findout background processes from OS:$ ps -ef|grep ora_|grep SID

Mandatory Background Processes

If any one of these 6 mandatory background processes is killed/not running, the instance will be aborted.

Database Writer (maximum 20) DBW0-DBW9,DBWa-DBWj

The DBWn processes are responsible for writing modified (dirty) buffers in the database buffer cache to disk. Although one database writer process (DBW0) is adequate for most systems, you can configure additional processes (DBW1 through DBW9 and DBWa through DBWj) to improve write performance if your system modifies data heavily. These additional DBWn processes are not useful on uniprocessor systems.

Multiple database writers can be configured by initialization parameter DB_WRITER_PROCESSES, depends on the number of CPUs allocated to the instance.

When a buffer in the database buffer cache is modified, it is marked dirty. A cold buffer is a buffer that has not been recently used according to the least recently used (LRU) algorithm. The DBWn process writes cold, dirty buffers to disk so that user processes are able to find cold, clean buffers that can be used to read new blocks into the cache. As buffers are dirtied by user processes, the number of free buffers diminishes. If the number of free buffers drops too low, user processes that must read blocks from disk into the cache are not able to find free buffers. DBWn manages the buffer cache so that user processes can always find free buffers.

Whenever a log switch is occurring as redolog file is becoming CURRENT to ACTIVE stage, oracle calls DBWn and synchronizes all the dirty blocks in database buffer cache to the respective datafiles, scattered or randomly.

DBWn will be invoked in following scenarios:1. When the dirty blocks in SGA reaches to a threshold value, oracle calls DBWn.2. When the database is shutting down with some dirty blocks in the SGA, then oracle

calls DBWn.

17

3. DBWn has a time out value (3 seconds by default) and it wakes up whether there are any dirty blocks or not.

4. When a checkpoint is issued.5. When a server process cannot find a clean reusable buffer after scanning a threshold

number of buffers. it signals DBWn to write.6. When a huge table wants to enter into SGA and oracle could not find enough free

space where it decides to flush out LRU blocks and which happens to be dirty blocks. Before flushing out the dirty blocks, oracle calls DBWn.

7. RAC ping request is made.8. When Table DROPed or TRUNCATEed.9. When tablespace is going to OFFLINE.10. When tablespace is going to READ ONLY.11. When tablespace is going to BEGIN BACKUP.

Log Writer (maximum 1) LGWR

LGWR writes redo data(redo entries) from redolog buffers to (online) redolog files, sequentially.

Redo log buffer works in circular fashion. It means that it overwrites old entries. But before overwriting, old entries must be copies to redo log files. Usually Log writer process (LGWR) is fast enough to mange these issues. Log writer process (LGWR) writes redo entries after certain amount of time to ensure that free space is available for new redo entries.

Redolog file has three stages CURRENT, ACTIVE, INACTIVE and this is a cyclic process. Newly created redolog file will be in UNUSED state.

When the LGWR is writing to a particular redolog file, that file is said to be in CURRENT status. If the file is filled up completely then a log switch takes place and the LGWR starts writing to the second file (this is the reason every database requires a minimum of 2 redolog groups). The file which is filled up now becomes from CURRENT to ACTIVE.

Log writer will write synchronously to the redo log groups in a circular fashion. If any damage is identified with a redo log file, the log writer will log an error in the LGWR trace file and the system Alert Log. Sometimes, when additional redo log buffer space is required, the LGWR will even write uncommitted redo log entries to release the held buffers. LGWR can also use group commits (multiple committed transaction's redo entries taken together) to write to redo logs when a database is undergoing heavy write operations.

LGWR will be invoked in following scenarios:

1. When user performs commitWhen a transaction is committed, a System Change Number (SCN) is generated and

tagged to it. Log writer puts a commit record in the redo log buffer and writes it to disk

18

immediately along with the transaction's redo entries. Changes to actual data blocks are deferred until a convenient time (Fast-Commit Mechanism).

2. After every three seconds

3. When redo log buffer is 1/3 full.

4. Shutting down the database.

5. DBWn process checks for redo entries, it signal LGWR process if redo entries have not

been written.

Checkpoint (maximum 1) CKPT

A Checkpoint is a background process. The checkpoint occurs when all modified database buffers in the Oracle SGA are written out to datafiles by the database writer (DBWn) process. After a checkpoint completes ,The checkpoint (CKPT) process writes checkpoint information(TimeStamp and SCN) to control files and data file headers.

(After a checkpoint completes, A checkpoint (CKPT) process in Oracle stores the SCN individually in the control file for each datafile. The following SQL shows the datafile checkpoint SCN for a single datafile in the control file .This SCN is called checkpoint SCN.)

Checkpoints occur AFTER (not during) every redo log switch and also at intervals specified

by initialization parameters.

Set parameter LOG_CHECKPOINTS_TO_ALERT=TRUE to observe checkpoint start and

end times in the database alert log.

Checkpoints can be forced with the ALTER SYSTEM CHECKPOINT; command.

Checkpoint event can be occurred in following conditions:

1. Whenever database buffer cache filled up.2. Whenever times out (3seconds until 9i, 1second from 10g).3. Log switch occurred.4. Whenever manual log switch is done.

SQL> ALTER SYSTEM SWITCH LOGFILE;5. Manual checkpoint.

SQL> ALTER SYSTEM CHECKPOINT;6. Graceful shutdown of the database.7. Whenever BEGIN BACKUP command is issued.8. When the time specified by the initialization parameter

LOG_CHECKPOINT_TIMEOUT (in seconds), exists between the incremental checkpoint and the tail of the log.

9. When the number of OS blocks specified by the initialization parameter LOG_CHECKPOINT_INTERVAL, exists between the incremental checkpoint and the tail of the log.The number of buffers specified by the initialization parameter FAST_START_IO_TARGET required to perform roll-forward is reached.

19

10. Oracle 9 i onwards, the time specified by the initialization parameter FAST_START_MTTR_TARGET (in seconds) is reached and specifies the time required for a crash recovery. The parameter FAST_START_MTTR_TARGET replaces LOG_CHECKPOINT_INTERVAL and FAST_START_IO_TARGET, but these parameters can still be used.

System Monitor (maximum 1) SMON

The System Monitor (SMON) is responsible for instance recovery by applying entries in the online redo log files to the datafiles. It also performs other activities as outlined in the figure shown below.

1. If the database is crashed (power failure) and next time when we restart the database SMON observes that last time the database was not shutdown gracefully. Hence it requires some recovery, which is known as INSTANCE CRASH RECOVERY. When performing the crash recovery before the database is completely open, if it finds any transaction committed but not found in the datafiles, will now be applied from redolog files to datafiles.

2. If SMON observes some uncommitted transaction which has already updated the table in the datafile, is going to be treated as a in doubt transaction and will be rolled back with the help of before image available in rollback segments .

3. SMON also cleans up temporary segments that are no longer in use.4. It also coalesces contiguous free extents in dictionary managed tablespaces that

have PCTINCREASE set to a non-zero value.5. In RAC environment , the SMON process of one instance can perform instance

recovery for other instances that have failed.6. SMON wakes up about every 5 minutes to perform housekeeping activities.

Process Monitor (maximum 1) PMON

The Process Monitor (PMON) is a cleanup type of process that cleans up after failed processes such as the dropping of a user connection due to a network failure or the abend of a user application program. It does the tasks shown in the figure below.

20

1. If a client has an open transaction which is no longer active (client session is closed) then PMON comes into the picture and that transaction becomes in doubt transaction which will be rolled back.

2. PMON is responsible for performing recovery if a user process fails. It will rollback uncommitted transactions. If the old session locked any resources that will be unlocked by PMON.

3. PMON is responsible for cleaning up the database buffer cache and freeing resources that were allocated to a process.

4. PMON also registers information about the instance and dispatcher processes with Oracle (network) listener.

5. PMON also checks the dispatcher & server processes and restarts them if they have failed.

6. PMON wakes up every 3 seconds to perform housekeeping activities.

Recoverer (maximum 1) RECO [Mandatory from 10g]

This process is intended for recovery in distributed databases. The distributed transaction recovery process finds pending distributed transactions and resolves them. All in-doubt transactions are recovered by this process in the distributed database setup. RECO will connect to the remote database to resolve pending transactions.

Pending distributed transactions are two-phase commit transactions involving multiple databases. The database that the transaction started is normally the coordinator. It will send request to other databases involved in two-phase commit if they are ready to commit. If a negative request is received from one of the other sites, the entire transaction will be rolled back. Otherwise, the distributed transaction will be committed on all sites. However, there is a chance that an error (network related or otherwise) causes the two-phase commit transaction to be left in pending state (i.e. not committed or rolled back). It's the role of the RECO process to liaise with the coordinator to resolve the pending two-phase commit transaction. RECO will either commit or rollback this transaction.

Memory Monitor process (MMON)

Collects statistics to help the database manage itself. The MMON process collects gathers memory statistics (snapshots) stores this information in the AWR which is used by the ADDM (automatic database diagnostic monitor), MMON is also responsible for issuing alerts for metrics that exceed their thresholds.

Processes

You need to understand three different types of Processes:● User Process : Starts when a database user requests to connect to an Oracle Server.

21

● Server Process : Establishes the Connection to an Oracle Instance when a User Process requests connection – makes the connection for the User Process.

● Background Processes : These start when an Oracle Instance is started up.

User and server processes

The processes shown in the figure are called user and server processes. These processes are used to manage the execution of SQL statements.

● A Shared Server Process can share memory and variable processing for multiple user processes.

● A Dedicates Server Process manages memory and variables for a single user process.

Connecting to an Oracle Instance – Creating a Session

System users can connect to an Oracle database through SQLPlus or through an application program like the Internet Developer Suite (the program becomes the system user). This connection enables users to execute SQL statements.

The act of connecting creates a communication pathway between a user process and an Oracle Server. As is shown in the figure above, the User Process communicates with the Oracle Server through a Server Process. The User Process executes on the client computer. The Server Process executes on the server computer, and actually executes SQL statements submitted by the system user.

The figure shows a one-to-one correspondence between the User and Server Processes. This is called a Dedicated Server connection. An alternative configuration is to use a Shared Server where more than one User Process shares a Server Process.

Sessions: When a user connects to an Oracle server, this is termed a session. The session starts when the Oracle server validates the user for connection. The session ends when the user logs out (disconnects) or if the connection terminates abnormally (network failure or client computer failure).

A user can typically have more than one concurrent session, e.g., the user may connect using SQLPlus and also connect using Internet Developer Suite tools at the same time. The limit of concurrent session connections is controlled by the DBA.

If a system users attempts to connect and the Oracle Server is not running, the system user receives the Oracle Not Available error message.

22

User Process

In order to use Oracle, you must obviously connect to the database. This must occur whether you're using SQLPlus, an Oracle tool such as Designer or Forms, or an application program.

This generates a User Process (a memory object) that generates programmatic calls through your user interface (SQLPlus, Integrated Developer Suite, or application program) that creates a session and causes the generation of a Server Process that is either dedicated or shared.

Server Process

As you have seen, the Server Process is the go-between for a User Process and the Oracle Instance. In a Dedicated Server environment, there is a single Server Process to serve each User Process. In a Shared Server environment, a Server Process can serve several User Processes, although with some performance reduction. Allocation of server process in a dedicated environment versus a shared environment is covered in further detail in the Oracle10g Database Performance Tuning course offered by Oracle Education.

Optional Background Processes

Archiver (maximum 10) ARC0-ARC9

We cover the Archiver (ARCn) optional background process in more detail because it is almost always used for production systems storing mission critical information. The ARCn process must be used to recover from loss of a physical disk drive for systems that are "busy" with lots of transactions being completed.

23

When a Redo Log File fills up, Oracle switches to the next Redo Log File. The DBA creates several of these and the details of creating them are covered in a later module. If all Redo Log Files fill up, then Oracle switches back to the first one and uses them in a round-robin fashion by overwriting ones that have already been used – it should be obvious that the information stored on the files, once overwritten, is lost forever.

If ARCn is in what is termed ARCHIVELOG mode, then as the Redo Log Files fill up, they are individually written to Archived Redo Log Files and LGWR does not overwrite a Redo Log File until archiving has completed. Thus, committed data is not lost forever and can be recovered in the event of a disk failure. Only the contents of the SGA will be lost if an Instance fails.

In NOARCHIVELOG mode, the Redo Log Files are overwritten and not archived. Recovery can only be made to the last full backup of the database files. All committed transactions after the last full backup are lost, and you can see that this could cost the firm a lot of $$$.

When running in ARCHIVELOG mode, the DBA is responsible to ensure that the Archived Redo Log Files do not consume all available disk space! Usually after two complete backups are made, any Archived Redo Log Files for prior backups are deleted.

24

The ARCn process is responsible for writing the online redolog files to the mentioned archive log destination after a log switch has occurred. ARCn is present only if the database is running in archivelog mode and automatic archiving is enabled. The log writer process is responsible for starting multiple ARCn processes when the workload increases. Unless ARCn completes the copying of a redolog file, it is not released to log writer for overwriting.

The number of archiver processes that can be invoked initially is specified by the initialization parameter LOG_ARCHIVE_MAX_PROCESSES (by default 2, max 10). The actual number of archiver processes in use may vary based on the workload.

ARCH processes, running on primary database, select archived redo logs and send them to standby database. Archive log files are used for media recovery (in case of a hard disk failure and for maintaining an Oracle standby database via log shipping). Archives the standby redo logs applied by the managed recovery process (MRP).

Coordinated Job Queue Processes (maximum 1000) CJQ0/JnnnJob queue processes carry out batch processing. All scheduled jobs are executed by these processes. The initialization parameter JOB_QUEUE_PROCESSES specifies the maximum job processes that can be run concurrently. These processes will be useful in refreshing materialized views.

This is the Oracle’s dynamic job queue coordinator. It periodically selects jobs (from JOB$) that need to be run, scheduled by the Oracle job queue. The coordinator process dynamically spawns job queue slave processes (J000-J999) to run the jobs. These jobs could be PL/SQL statements or procedures on an Oracle instance.

From 11 g release 2 , DBMS_JOB and DBMS_SCHEDULER work without setting JOB_QUEUE_PROCESSES. Prior to 11gR2 the default value is 0, and from 11gR2the default value is 1000.

Lock Monitor (maximum 1) LMONLock monitor manages global locks and resources. It handles the redistribution of instance locks whenever instances are started or shutdown. Lock monitor also recovers instance lock information prior to the instance recovery process. Lock monitor co-ordinates with the Process Monitor (PMON) to recover dead processes that hold instance locks.

Lock Manager Daemon (maximum 10) LMDnLMDn processes manage instance locks that are used to share resources between instances. LMDn processes also handle deadlock detection and remote lock requests.

Global Cache Service (LMS)In an Oracle Real Application Clusters environment, this process manages resources and provides inter-instance resource control.

Lock processes (maximum 10) LCK0- LCK9

25

The instance locks that are used to share resources between instances are held by the lock processes.

Block Server Process (maximum 10) BSP0-BSP9Block server Processes have to do with providing a consistent read image of a buffer that is requested by a process of another instance, in certain circumstances.

Queue Monitor (maximum 10) QMN0-QMN9This is the advanced queuing time manager process. QMNn monitors the message queues.

Event Monitor (maximum 1) EMN0/EMONThis process is also related to advanced queuing, and is meant for allowing a publish/subscribe style of messaging between applications.

Dispatcher (maximum 1000) DnnnIntended for multi threaded server (MTS) setups. Dispatcher processes listen to and receive requests from connected sessions and places them in the request queue for further processing. Dispatcher processes also pickup outgoing responses from the result queue and transmit them back to the clients. Dnnn are mediators between the client processes and the shared server processes. The maximum number of dispatcher process can be specified using the initialization parameter MAX_DISPATCHERS.

Shared Server Processes (maximum 1000) SnnnIntended for multi threaded server (MTS) setups. These processes pickup requests from the call request queue, process them and then return the results to a result queue. The number of shared server processes to be created at instance startup can be specified using the initialization parameter SHARED_SERVERS. Maximum shared server processes can be specified by MAX_SHARED_SERVERS.

Parallel Execution Slaves (maximum 1000) PnnnThese processes are used for parallel processing. It can be used for parallel execution of SQL statements or recovery. The Maximum number of parallel processes that can be invoked is specified by the initialization parameter PARALLEL_MAX_SERVERS.

Trace Writer (maximum 1) TRWRTrace writer writes trace files from an Oracle internal tracing facility.

Input/Output Slaves (maximum 1000) InnnThese processes are used to simulate asynchronous I/O on platforms that do not support it. The initialization parameter DBWR_IO_SLAVES is set for this purpose.

Dataguard Monitor (maximum 1) DMONThe Dataguard broker process. DMON is started when Dataguard is started.

Managed Recovery Process MRPThis process will apply archived redo log to the standby database.

26

Remote File Server process RFSThe remote file server process on the standby database receives archived redo logs from the primary database.

Wakeup Monitor Process (maximum 1) WMONThis process was available in older versions of Oracle to alarm other processes that are suspended while waiting for an event to occur. This process is obsolete and has been removed.

Recovery Writer (maximum 1) RVWRThis is responsible for writing flashback logs (to FRA).

Fetch Archive Log (FAL) ServerServices requests for archive redo logs from FAL clients running on multiple standby databases. Multiple FAL servers can be run on a primary database, one for each FAL request.

Fetch Archive Log (FAL) ClientPulls archived redo log files from the primary site. Initiates transfer of archived redo logs when it detects a gap sequence.

New Background Processes in Oracle 10 g

Memory Manager (maximum 1) MMANMMAN dynamically adjust the sizes of the SGA components like DBC, large pool, shared pool and java pool. It is a new process added to Oracle 10g as part of automatic shared memory management.

Memory Monitor (maximum 1) MMONMMON monitors SGA and performs various manageability related background tasks.

Memory Monitor Light (maximum 1) MMNLNew background process in Oracle 10g.

Change Tracking Writer (maximum 1) CTWRCTWR will be useful in RMAN. Optimized incremental backups using block change tracking (faster incremental backups) using a file (named block change tracking file). CTWR (Change Tracking Writer) is the background process responsible for tracking the blocks.

ASMBThis ASMB process is used to provide information to and from cluster synchronization services used by ASM to manage the disk resources. It's also used to update statistics and provide a heart beat mechanism.

Re-Balance RBALRBAL is the ASM related process that performs rebalancing of disk resources controlled by ASM.

27

Actual Rebalance ARBxARBx is configured by ASM_POWER_LIMIT.

New Background Processes in Oracle 11 g ● ACMS - Atomic Controlfile to Memory Server● DBRM - Database Resource Manager● DIA0 - Diagnosibility process 0● DIAG - Diagnosibility process● FBDA - Flashback Data Archiver● GTX0 - Global Transaction Process 0● KATE - Konductor (Conductor) of ASM Temporary Errands● MARK - Mark Allocation unit for Resync Koordinator (coordinator)● SMCO - Space Manager● VKTM - Virtual Keeper of TiMe process● W000 - Space Management Worker Processe

28