7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 1/32

5 Managing the Oracle Instance

This chapter discusses the Oracle instance and database.

The following topics are covered:

  Overview of an Instance and Instance Management 

  Shutting Down and Restarting the Instance and Database 

  Viewing and Modifying Initialization Parameters 

  Managing Memory Parameters 

  Instances: Oracle by Example Series 

Overview of an Instance and Instance Management

Your Oracle Database is comprised of a set of operating system files containing data entered by

users or applications and structural information about the database itself called databasemetadata. Information is stored persistently in these files.

In order for you to view or update the data contained in the database, Oracle needs to start a set

of processes, called background processes, and needs to allocate some memory to be used duringdatabase operation. The background processes and memory allocated by Oracle are together 

known as an instance. Therefore before the database can be used, the database instance must be

started. When the database instance is not available, your data is safe in the database but it

cannot be accessed by any user or application.

The properties of a database instance are specified using instance initialization parameters. When

the instance is started, an initialization parameter file is read and the instance is configuredaccordingly.

The Oracle instance and the Oracle database are separate entities, although the term instance is

often used to mean one or the other or both. Technically, they are distinguished as follows:

  An Oracle instance consists of the shared memory structures and background processes

that run the Oracle database. You can have an instance without a database (for example,

when you have not yet created a database), and if a database exists, it can be open or not.

  A database instance refers to the physical and logical components of a specific database,and its operation.

This section presents some of the concepts of an instance and its functioning. It is intended thatthese concepts can provide a basis for understanding instance management. The following topics

are discussed:

  Instance Memory Structure 

  Oracle Background Processes   Accessing the Database 

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 2/32

  About Initialization Parameters 

Instance Memory Structure

This section briefly describes the memory structures of an instance. The size of these structures

affects the performance of the Oracle database server and is controlled by initialization parameters. These initialization parameters can be categorized as memory parameters.

When a database is created with DBCA, the memory parameters are automatically set to optimalvalues based on your specification of the database workload. However, as your database usage

expands, you might find it necessary to alter the settings of the memory parameters.

Oracle provides alerts and advisors to identify memory sizing problems and to help you

determine appropriate values for memory parameters.

The System Global Area (SGA)

The SGA is a shared memory area that contains data and control information for the instance.Multiple users can share data within this memory area (controlled by Oracle) and information

stored in the SGA can avoid repeated access from physical disk, a time consuming operation.

For optimal performance, the SGA should be large enough to avoid frequent disk reads and

writes.

The SGA has several subcomponents as listed in the following table:

Component Description

Buffer Cache Before any data stored in the database can be queried or modified, it must be read

from disk and stored in memory. The buffer cache is the component of the SGAthat acts as the buffer to store any data being queried or modified. All user 

 processes connected to the database share access to the buffer cache.

Shared Pool The shared pool caches information that can be shared among users. Some

examples:

  SQL statements are cached so that they can be reused

  Information from the data dictionary such as user account data, table and

index descriptions, and privileges is cached for quick access and

reusability  Stored procedures, which are executable code that is stored in the

database, can be cached for faster access

Redo LogBuffer 

This buffer improves performance by caching redo information (used for instance recovery) until it can be written at once and at a more opportune time to

the physical redo log files that are stored on disk. Redo information and redo log

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 3/32

Component Description

files are discussed in "Redo Log Files". 

Large Pool This is an optional area that is used for buffering large I/O requests for variousserver processes.

Java Pool The Java pool memory is used for all session-specific Java code and data withinthe Java Virtual Machine (JVM)

Streams Pool The Streams pool is used by the Oracle Streams product.

Program Global Area (PGA)

A program global area (PGA) is a memory area used by a single Oracle server process. A server 

 process is a process that services a client's requests. Each server process has its own private PGA

area that is a nonshared area of memory created by Oracle when a server process is started.

The PGA is used to process SQL statements and to hold logon and other session information.

The amount of PGA memory used and its content depends on the instance configuration, that is,

whether the instance is running in dedicated server or shared server mode.

See Also: 

"Managing Memory Parameters" 

Oracle Background Processes

Oracle creates a set of background processes for an instance that interact with each other and

with the operating system to manage memory structure, asynchronously perform I/O to writedata to disk, and do general housekeeping. The background processes consolidate functions that

would otherwise be handled by multiple Oracle programs running for each user process. Theyasynchronously perform I/O and monitor other Oracle processes to provide increased parallelism

for better performance and reliability.

There are many background processes and not all may be present depending upon the features

that are being used in the database. The most common background processes, and ones that most

directly affect you, are the following:

BackgroundProcess Description

Database Writer The database writer writes modified blocks from the database buffer cache to

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 4/32

BackgroundProcess Description

(DBWn) the files on disk. Oracle allows a maximum of 20 database writer processes.

Log Writer 

(LGWR)

The log writer process writes redo log entries to disk. Redo log entries are

generated in the redo log buffer of the SGA and the log writer process writesthe redo log entries sequentially into an online redo log file.

Checkpoint At specific times, all modified database buffers in the SGA are written to thedatafiles by a database writer process (DBWn). This event is called a

checkpoint. The checkpoint process is responsible for signalling DBWn at

checkpoints and updating all of the datafiles and control files of the database toindicate the most recent checkpoint.

System Monitor (SMON)

The system monitor performs crash recovery when a failed instance starts upagain.

Process Monitor 

(PMON)

The process monitor performs process recovery when a user process fails. It is

responsible for cleaning up the cache and freeing resources that the failed process was using.

Archiver 

(ARCn)

When the database is running in archive log mode, one or more archiver 

 processes copy the redo log files to archival storage when the log files are full

or a log switch occurs. For more information, see Chapter 9, "Performing

Backup and Recovery".

Accessing the Database

The database instance can be started (made available) only by an authorized databaseadministrator who has a special type of connection privilege to the Oracle instance. After the

database instance has been started, it is usually open for access by normal users for whom

database user accounts have been created. Later, you will learn how to start up and shut down anOracle instance and database in "Shutting Down and Restarting the Instance and Database". 

This section describes the process of starting the Oracle instance and database and the creation of 

server processes that enable user access.

How the Oracle Instance and Database are Started

The administrator who starts up the Oracle instance and database must connect to the instancewith a special kind of connection privilege. There are two of these privileges: SYSDBA for fully

empowered database administrators and SYSOPER for users who operate the database, but have no

 privileges to access user objects. Authorization to use these privileges occurs either through the

operating system or through a special password file.

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 5/32

When you create an Oracle database, there are two primary administrative user accounts who are

automatically created: SYS and SYSTEM. Both of these users have full database administration

 privileges granted to them, but only user SYS can initially connect with the SYSDBA privilege.

The Startup Process

The process of starting the instance and database is as follows:

1.  You start the instance in one of the following ways:

  Use Oracle Enterprise Manager. See "Shutting Down and Restarting the Instance

and Database".

  Use the STARTUP statement using SQL*Plus. See Oracle Database Administrator's Guide 

  On Windows, you can start the Oracle services. See "Starting and Shutting Down

the Database Instance on Windows".

Oracle reads the initialization parameter file, allocates SGA memory, and starts the background processes for the instance.

If you also specify that the database is to be mounted, then the instance opens the

database control file. The database is now said to be in the mount state. This state enablesadministrators to perform certain administrative functions that cannot be performed when other 

users are accessing the database.

If you specify that the database is to be opened, then the instance opens the redo log filesand datafiles for the database. The database is now open and available for all user access.

The default startup behavior is to complete the three stages as described earlier. Unlessexplicitly specified otherwise, the instance will be started, database mounted and opened.

The Shutdown Process

The process is reversed when you shut down the database.

1.  You issue the statement to shutdown the database by similar means as explained in "The

Startup Process". Any modified data blocks that are cached in the SGA and have not been

written to disk are now written to disk. The redo log buffer is similarly flushed. Datafilesare checkpointed and their headers are marked current as of the time the database was

closed. Datafiles and log files are closed. Users can no longer access the database.

2.  The Oracle instance dismounts the database and updates relevant entries in the control

file to record a clean shutdown. The control file is closed. The database is now closed andonly the instance remains.

3.  The Oracle instance stops the background processes of the instance and deallocates the

shared memory used by the SGA.

Server and Client Processes

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 6/32

In addition to background processes, Oracle creates server processes that handle the requests of 

user or client processes that connect to the instance. A user connection is composed of two

distinct pieces:

  A client program acting on behalf of the user, such as Oracle Enterprise Manager,

SQL*Plus, or an application  A server process that handles the connection to the database on behalf of the client

 program

In some situations when the client and Oracle operate on the same machine, it is possible to

combine the user process and corresponding server process into a single process to reduce

system overhead. However, when the client and Oracle operate on different machines, a user  process always communicates with Oracle through a separate server process.

Server processes can be either dedicated or shared. In dedicated server mode, each client processhas its own server process. While a dedicated server process is good for long running queries and

administrative tasks, an idle process or too many dedicated processes can result in an inefficientuse of resources.

Shared server mode eliminates the need for a dedicated server process for each connection. A

dispatcher directs multiple incoming network session requests to a pool of shared server  processes. An idle shared server process from a shared pool of server processes picks up arequest from a common queue, which means a small number of shared servers can perform the

same amount of processing as many dedicated servers. Also, because the amount of memory

required for each user is relatively small, less memory and process management are required, andmore users can be supported.

Shared server mode is more efficient at supporting multiple users and clients making frequentshort-running queries.

Network Connections

Oracle Net is a layer of software that allows different physical machines to communicate toaccessing an Oracle database. A version of Oracle Net runs on the client machine and on the

database server. The client machine and the database server are often the same machine.

Oracle Net enables the client and server to communicate over a network using many popular 

network protocols, and it provides location transparency such that the client machine does not

need to know the server's location. When the database is moved to another location, you onlyneed to reconfigure Oracle Net. No changes are necessary to client applications.

Oracle Net must be separately configured and started for it to handle client connections to thedatabase. You can configure Oracle Net using Oracle Enterprise Manager or with a separately

launched GUI tool called the Oracle Net Manager. To learn more, see Chapter 4, " Configuring

the Network Environment ". 

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 7/32

When an instance starts, a listener process establishes a communication pathway to Oracle.

When a user process makes a connection request, the listener determines whether it should use a

shared server dispatcher process or a dedicated server process and establishes an appropriateconnection.

About Initialization Parameters

Instance management involves configuring parameters that affect the basic operation of the

database instance. These parameters are called initialization parameters. The Oracle database

server reads these parameters at database startup and monitors them while the database isrunning. They are stored in memory, where many of them can be changed dynamically. There

are two types of parameter files, and whether these dynamic changes are persistent across

database shutdown and startup depends upon the type of parameter file you are using.

  Server parameter file

This, the preferred form of initialization parameter file, is contained in a binary file thatcan be written to and read by the database server. It must not be edited manually. It

resides on the machine that Oracle is running on, and is persistent across shutdown andstartup.

  Text initialization parameter file

This type of initialization parameter file can be read by the database server, but it is not

written to by the server. In this file, you can set initialization parameters with a text editor for them to be persistent across shutdown and startup.

Shutting Down and Restarting the Instance andDatabase

If you need to shut down and later restart your instance or database, you can do this with

the Shutdown or Startup button, under the General heading on the Database Home page as

shown in Figure 5 – 1, "Shutdown/Startup Button on Home Page".

Figure 5-1 Shutdown/Startup Button on Home Page 

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 8/32

 Description of the illustration hp-shutdown.gif  

The first page to appear is Startup/Shutdown: Specify Host and Target Database Credentials.

This page requires you to log in to the machine that Oracle is running on, and into the database

itself with SYSDBAor SYSOPER privileges. The next screen enables you to shut down the database,or start up the database, specifying options.

Starting and Shutting Down the Database Instance on Windows

You can start and shut down your Oracle database with the Windows Services program. To startOracle, you must start three services:

  OracleService<SID>, which is your Oracle Database instance

  Oracle<oracle_home><SID>TNSListener, which is your listener required to allow clients

to connect to your database  Oracle<oracle_home><SID>DBConsole, which enables clients to connect to Enterprise

Manager 

To start these services:

1.  From the Control Panel, select Administrative Tools->Services. A list of all availableservices on you system appears.

2.  Locate the three Oracle services listed earlier. For example, if your SID is Sales1 and

Oracle home is OraHome10, then locate the following services:

  OracleServiceSales1

  OracleOraHome10Sales1TNSListener 

  OracleOraHome10Sales1DBConsole

Start all three services. You can start a service by right-clicking the service, and selecting

Start. You can also choose Start from the Actions menu. If you double click the service, theservice properties page appears where you can Start or Stop the service, and select your Startup

Type.

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 9/32

To shut down the database, you do the reverse: locate the services and stop them, by selecting

Stop from the Actions menu.

Viewing and Modifying Initialization Parameters

When you install one of the preconfigured databases provided by Oracle, the initialization parameters are optimized for normal use in the environment that you specified. It is not

necessary for you to alter any initialization parameters at this time. The steps described in this

section will familiarize you with the initial parameter setting for your database and indicate how

to modify parameters.

To view or modify the initialization parameters for your database:

1.  From the Database Home page, click the Administration property page. The next page

that you see is the Administration home page shown in Figure 5-2. 

Figure 5-2 Database Administration Page 

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 10/32

 

Description of the illustration admin-page-updated1.gif  

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 11/32

2.  Click All Initialization Parameters under the Instance heading.

Enterprise Manager displays the Initialization Parameters page comprised of a tablelisting the current value of each initialization parameter as seen by the database instance.

You can also use this page to alter initialization parameter values, using the Show

SQL, Revert, and Apply buttons.

There are two property pages shown on the Initialization Parameters page:

  Current — The table on this property page displays all of the initialization

 parameter values currently seen by the database instance (in memory).

You can use this page to make dynamic changes to parameters in the current

running instance. Only parameters marked dynamic can be changed. To do so,

enter a new value and click Apply.

 SPFile — This property page is present when you are using a server parameter file,whose location is displayed a the top of the table. This property page shows parameter settings in the server parameter file.

Changes to parameter settings in this file are persistent across instance startup and

shutdown. To make persistent changes to an initialization parameter, enter the

new value and click Apply. You can optionally apply changes to the currentrunning instance by checking Apply changes in SPFile to the current running

instance. If you do not check this box, your changes will not take effect until the

database is shut down and restarted.

Parameters marked as Basic represent a small subset of all initialization parameters, andare considered necessary to keeping the database running and healthy.

As the number of database users grows and workload increases, you might need to alter 

some initialization parameters. You can make these changes directly using the

Initialization Parameter page as described, or indirectly using one of the advisors provided by Oracle. One such advisor, the memory advisor, is described in "Managing

Memory Parameters". 

Managing Memory Parameters

Some initialization parameters, referred to here as memory parameters, determine the total sizeof the system global area (SGA) and the program global area (PGA), and of the subcomponentsof the SGA. The settings of memory parameters can affect the performance of your database.

When you install your database, these parameters are tuned to meet the requirements of the

environment that you specify.

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 12/32

If you enabled Automatic Shared Memory Configuration when you configured your database,

Oracle automatically sizes the subcomponents of the SGA, which include the shared pool and

 buffer cache. Oracle recommends that you enable memory auto tuning.

If Automatic Shared Memory Management is disabled, you can enable it on the Memory

Parameters page. You can navigate to this page from the Administration page byclicking Memory Parametersunder the Instance heading. From this page you can enable or 

disable Automatic Shared Memory Management and view your SGA and PGA memory settings

from their property pages.

Modifying Memory Parameters

To modify the size of an SGA subcomponent without bringing your instance down,

you can disable Automatic Shared Memory Management on the Memory Parameters

 page. With the Advice button on the Memory Parameters page, the Memory Advisor 

(discussed in "Using the Memory Advisor" in Chapter 10, "Monitoring and Tuning

the Database") gives you advice on optimal memory settings. If you choose to modifyyour memory settings manually, you can enter new sizes and apply changes

dynamically while the instance is up. You can also do so from the Current property

 page on the Initialization Parameters page. However, there are some restrictions on

dynamic modification of memory parameters. For more information, see Oracle

 Database Administrator's Guide. 

To make changes to memory parameters persistent across instance startup and

shutdown, you must alter your parameter file. You can do so by navigating to SPFile

 property page from the Memory Parameters page and making your changes there.

15 Process Architecture

This chapter discusses the processes in an Oracle database.

This chapter contains the following sections:

  Introduction to Processes   Overview of Client Processes 

  Overview of Server Processes 

  Overview of Background Processes 

Introduction to Processes

 A  process is a mechanism in an operating system that can run a series of steps. Themechanism depends on the operating system. For example, on Linux an Oraclebackground process is a Linux process. On Windows, an Oracle background process is athread of execution within a process.

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 13/32

Code modules are run by processes. All connected Oracle Database users must run thefollowing modules to access a database instance: 

   Application or Oracle Database utility

 A database user runs a database application, such as a precompiler program ora database tool such as SQL*Plus, that issues SQL statements to a database.

  Oracle database code

Each user has Oracle database code executing on his or her behalf thatinterprets and processes the application's SQL statements.

 A process normally runs in its own private memory area. Most processes canperiodically write to an associated trace file (see "Trace Files").

See Also:"Tools for Database Administrators" and "Tools for Database Developers" 

Multiple-Process Oracle Database Systems

Multiple-process Oracle (also called multiuser Oracler/span> (also c)s Orsof of ales the applio folldifferessepartps. Ticatatabase Systems).Ticathatcangivepsgoodcallbasman> 

Types of Processes 

 A database instance contains or interacts with the following types of processes:

  Client processes run the application or Oracle tool code.  Oracle processes run the Oracle database code. Oracle processes

including the following subtypes:o  Background processes start with the database instance and

perform maintenance tasks such as performing instancerecovery , cleaning up processes, writing redo buffers to disk, andso on.

o Server processes perform work based on a client request.

For example, these processes parse SQL queries, place them inthe shared pool , create and execute a query plan for each query , and read buffers from the database buffer cache or from disk.

Note:

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 14/32

Server processes, and the process memory allocated in theseprocesses, run in the instance. The instance continues to function whenserver processes terminate.

o  Slave processes perform additional tasks for a background or

server process.

The process structure varies depending on the operating system and thechoice of Oracle Database options. For example, the code for connected userscan be configured for dedicated server or shared server connections. In ashared server architecture, each server process that runs database code canserve multiple client processes.

Figure 15-1 shows a system global area (SGA) and background processesusing dedicated server connections. For each user connection, the applicationis run by a client process that is different from the dedicated server process

that runs the database code. Each client process is associated with its ownserver process, which has its own program global area (PGA). 

Figure 15-1 Oracle Processes and the SGA

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 15/32

 Description of "Figure 15-1 Oracle Processes and the SGA" 

See Also:  "Dedicated Server Architecture" and "Shared Server Architecture"  

 Your Oracle Database operating system-specific documentation formore details on configuration choices  Oracle Database Reference  to learn about the V$PROCESS view

Overview of Client Processes

When a user runs an application such as a Pro*C program or SQL*Plus, theoperating system creates a client process (sometimes called a user process)

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 16/32

to run the user application. The client application has Oracle Databaselibraries linked into it that provide the APIs required to communicate withthe database.

Client and Server Processes

Client processes differ in important ways from the Oracle processesinteracting directly with the instance. The Oracle processes servicing theclient process can read a serrs fOraclr Pr an assoc/a>n fvide tns an ant request.sqlpl> nr="w 

sese piew

a hrefonhe >V$PROCESSsqlpl> ocess can read>

  ps oxml:"0" e="pre2/e25" cclass=arn" summarypr% ps -ef | grep -e sese p -esqlpl>< | grep -v grep ocess an a29437a29436 0cle:40 pts/1 00:00:00 sqlpl><

asneatdba!--precle dannt prcode. Eachessas of ure,s. Ticats the applbaseeproer/"w

sqlpl> nr="w

sese piew

a hrefarocess that runsinstaay rnn thlon, the applibodeno ocess can read>

  ps oxml:"0" e="pre2/e25" cclass=arn" summarypr% ps -ef | grep -e sese p -esqlpl>< | grep -v grep ocess an a29441 1 0cle:40 ? 00:00:00 oraclesese p(LOCAL=NO)!--preculid="i1Headect2">Multipld="ii16690" na8532i16690"> <7ivclass="sect2">

Types of Cs. For eacer Procsrsiop> A connection is a physical communication pathwaybetween a client process and a database instance. A communication pathway isestablished using available interprocess communication mechanisms or network software. Typically, a connection occurs between a client process and a server processor dispatcher, but it can also occur between a client process and Oracle ConnectionManager (CMAN). 

 A session is a logical entity in the database instance memory that represents the state of a current user login to a database. For example, when a user is authenticated by thedatabase with a password, a session is established for this user. A session lasts from thetime the user is authenticated by the database until the time the user disconnects or

exits the database application.

 A single connection can have 0, 1, or more sessions established on it. The sessions areindependent: a commit in one session does not affect transactions in other sessions.

Note:

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 17/32

If Oracle Net connection pooling is configured, then it is possible for a connection todrop but leave the sessions intact.

Multiple sessions can exist concurrently for a single database user. As shown in Figure15-2 , user hrcan have multiple connections to a database. In dedicated server

connections, the database creates a server process on behalf of each connection. Only

the client process that causes the dedicated server to be created uses it. In a sharedserver connection, many client processes access a single shared server process.

Figure 15-2 One Session for Each Connection 

Description of "Figure 15-2 One Session for Each Connection" 

Figure 15-3 illustrates a case in which user hr has a single connection to a database, but

this connection has two sessions.

Figure 15-3 Two Sessions in One Connection 

Description of "Figure 15-3 Two Sessions in One Connection" 

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 18/32

Generating an autotrace report of SQL statement execution statistics reicd to-s aservssioncenario href="#BABDBIJC"BFigure 15-3 illus.ef="#BABDBIJC"CADBan E,when/a>, userrn, the ig, that ilsoc/a>hr has a te a nnterilsr" celdata ils a sautork won does n(sese p outpcan the feddiv class="infoboxne, whenclass="titleinfiguree, whencl"BABBCEEF"GDIIB="BABBCEEF"GDIIB=aid="CNCPT89081" nam2="CNCPT89081">,1onnection" 

ps oxml:"0" e="pre2/e25" cclass=arn" summaryproQL> SELECT SID, SERIAL#,PADDR FROM V$SESSION WHERE USERNAME = USER; SID SERIAL# PADDR -ss=-------=-------- 90 91 3BE2E41C roQL> SET AUTOTRACE ON STATISTICS;roQL> SELECT SID,SERIAL#, PADDR FROM V$SESSION WHERE USE = USER; SID SERIAL# PADDR --- --------------- 88 93 3BE2E41C 90 91 3BE2E41C ... SQL> DISCONNECT

  The DISCONNECT command in Example 15-1 actually ends the sessions, not theconnection. Opening a new terminal and connecting to the instance as adifferent user, the query in Example 15-2 shows that the connection

from  Example 15-1 is still active.

Example 15-2 Connection with No Sessions 

v WHERE ADDR = HEXTORAW('41C

...

');

PROGRAM 

------------------------------------------------

oracle@stbcs09,1o(TNS V1-V3)!--preculid="i1Headect2">Mle" --> 

Thes="infoboxnotealso"> 

See Also:

"Shared Server Architecture" 

v> 

Overvie"BABBCEEF"Gerviewd="CNCPT1245" ame="8NCPT1246"> <8iv class="sect2">  

Overview of Client Processes 

Cliid="sthref1824" name=4e="sthref1830">Oracle Database creates server processes to handle the requests of client processes connected to theinstance. A client process always communicates with a database through aseparate server process.

Server processes created on behalf of a database application can perform oneor more of the following tasks:

  Parse and run SQL statements issued through the application, including

creating and executing the query plan (see "Stages of SQLProcessing")

  Execute PL/SQL code

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 19/32

  Read data blocks from data files into the database buffer cache (theDBW n background process has the task of writing modified blocks back todisk)

  Return results in such a way that the application can process theinformation

Dedicated Server Processes

In dedicated server connections, the client connection is associated with one

and only one server process (see "Dedicated Server Architecture"). OnLinux, 20 client processes connected to a database instance are serviced by20 server processes.

Each client process communicates directly with its server process. Thisserver process is dedicated to its client process for the duration of thesession. The server process stores process-specific information and 

the UGA in its PGA (see "PGA Usage in Dedicated and Shared Server Modes").

Shared Server Processes

In shared server connections, client applications connect over a network to

a dispatcher process, not a server process (see "Shared Server Architecture"). For example, 20 client processes can connect to a singledispatcher process.

The dispatcher process receives requests from connected clients and puts them 

into a request queue in the large pool (see "Large Pool"). The firstavailable shared server process takes the request from the queue and  processes it. Afterward, the shared server place the result into thedispatcher response queue. The dispatcher process monitors this queue and transmits the result to the client.

Like a dedicated server process, a shared server process has its own PGA.However, the UGA for a session is in the SGA so that any shared server canaccess session data.

Overview of Background Processes

 A multiprocess Oracle database uses some additional processescalled background processes. The background processes perform maintenancetasks 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. For example, the LGWR process writes data from the redo log buffer to the online redo log. When a filled log file is ready to bearchived, LGWR signals another process to archive the file.

Oracle Database creates background prosses access utoon aite to a fillbaseinstance are h theuteratr/span> 

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 20/32

ps oxml:"0" e="pre2/e25" cclass=arn" summaryproELECT P= USE FROM V$code> v WHERE P= USEIS NOT NULL ORDER BY P= US;!--precle d servern is asthe fellowingsectionstopicul> 

  I>I">Manda> ayund Processes 

I>  I> 

See Also:Oracle Database Reference for descriptions of all the background processes

 Mandatory Background Processes

The mandatory background processes are present in all typical databaseconfigurations. These processes run by default in a database instance started 

 with a minimally configured initialization parameter file (see Example 13-1).

This section describes the following mandatory background processes:

  Process Monitor Process (PMON)   System Monitor Process (SMON)   Database Writer Process (DBW n)   Log Writer Process (LGWR)   Checkpoint Process (CKPT)    Manageability Monitor Processes (MMON and MMNL)   Recoverer Process (RECO) 

See Also:

  Oracle Database Reference for descriptions of other mandatory processes, including MMAN, DIAG, VKTM, DBRM, and PSP0

  Oracle Real Application Clusters Administration and Deployment

Guide and  Oracle Clusterware Administration and Deployment Guide for more information about background processes specific to Oracle RAC and Oracle Clusterware

Process Monitor Process (PMON)

The process monitor (PMON) monitors the other background processes and  performs process recovery when a server or dispatcher process terminatesabnormally. PMON is responsible for cleaning up the database buffer cache and freeing resources that the client process was using. For example, PMON resetsthe status of the active transaction table, releases locks that are no longerrequired, and removes the process ID from the list of active processes.

PMON also registers information about the instance and dispatcher processes

 with the Oracle Net listener (see "The Oracle Net Listener"). When aninstance starts, PMON polls the listener to determine whether it is running.

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 21/32

If the listener is running, then PMON passes it relevant parameters. If it isnot running, then PMON periodically attempts to contact it.

System Monitor Process (SMON)

The system monitor process (SMON) is in charge of a variety of system-level

cleanup duties. The duties assigned to SMON include:

  Performing instance recovery, if necessary, at instance startup. In anOracle RAC database, the SMON process of one database instance can perform instance recovery for a failed instance.

  Recovering terminated transactions that were skipped during instancerecovery because of file-read or tablespace offline errors. SMONrecovers the transactions when the tablespace or file is brought backonline.

  Cleaning up unused temporary segments. For example, Oracle Databaseallocates extents when creating an index. If the operation fails, thenSMON cleans up the temporary space.

  Coalescing contiguous free extents within dictionary-managed 

tablespaces.

SMON checks regularly to see whether it is needed. Other processes can callSMON if they detect a need for it.

Database Writer Process (DBW n)

Thedispae with a er Propess (DBW is es dataonnectits witfilabase buffer cassoc n backcesses withan asfied blocker cas database instanfer cache andisk)).

d="sthref1867"7name="sthref1860"7A singllth the database ins er Propess(DBW <spj — ts="" cmhe="" ans="" er="" pformance="" for="" theye="" datem="" monited="" blta="" fromheavi="" pmose="" protional="" procspan=""class="italic" style="font-style: italic;">n backcesses wit no lor,thfulperauncess Orastems.

The DBW n process writes dirty buffers to disk under the following conditions:

   When a server process cannot find a clean reusable buffer afterscanning a threshold number of buffers, it signals DBW n to write.DBW n writes dirty buffers to disk asynchronously if possible while performing other processing.

  DBW n periodically writes buffers to advance the checkpoint, which isthe 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.

In many cases the blocks that DBW n writes are scattered throughout the disk.Thus, the writes tend to be slower than the sequential writes performed byLGWR. DBW n performs multiblock writes when possible to improve efficiency.The number of blocks written in a multiblock write varies by operatingsystem.

See Also:

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 22/32

Oracle Database Performance Tuning Guide for advice on configuring, monitoring, and tuning DBW n 

Log Writer Process (LGWR)

The log writer process (LGWR) manages the redo log buffer. LGWR writes one

contiguous portion of the buffer to the online redo log. By separating thetasks of modifying database buffers, performing scattered writes of dirty buffers to disk, and performing fast sequential writes of redo to disk, thedatabase improves performance.

In the following circumstances, LGWR writes all redo entries that have beencopied into the buffer since the last time it wrote:

   A user commits a transaction (see "Committing Transactions").   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 n must write modified buffers to disk.

Before DBW n can write a dirty buffer, redo records associated withchanges to the buffer must be written to disk (the write-ahead  protocol). If DBW n finds that some redo records have not been written,it signals LGWR to write the records to disk and waits for LGWR tocomplete before writing the data buffers to disk.

LGWR and Commits

Oracle Database uses a fast commit mechanism to improve performance forcommitted transactions. When a user issues a COMMIT statement, the transaction

is assigned a system change number (SCN). LGWR puts a commit record in theredo log buffer and writes it to disk immediately, along with the commit SCNand transaction's redo entries.

The redo log buffer is circular. When LGWR writes redo entries from the redolog buffer to an online redo log file, server processes can copy new entriesover the entries in the redo log buffer that have been written to disk. LGWR normally writes fast enough to ensure that space is always available in the buffer for new entries, even when access to the online redo log is heavy.

The atomic write of the redo entry containing the transaction's commit record is the single event that determines the transaction has committed. OracleDatabase returns a success code to the committing transaction although the

data buffers have not yet been written to disk. The corresponding changes todata blocks are deferred until it is efficient for DBW n to write them to thedata files.

 Note:LGWR can write redo log entries to disk before a transaction commits. Theredo entries become permanent only if the transaction later commits.

 When activity is high, LGWR can use group commits. For example, a usercommits, causing LGWR to write the transaction's redo entries to disk. During

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 23/32

this write other users commit. LGWR cannot write to disk to commit thesetransactions until its previous write completes. Upon completion, LGWR can write the list of redo entries of waiting transactions (not yet committed) inone operation. In this way, the database minimizes disk I/O and maximizes performance. If commits requests continue at a high rate, then every write byLGWR can contain multiple commit records.

LGWR and Inaccessible Files

LGWR writes synchronously to the active mirrored group of online redo logfiles. If a log file is inaccessible, then LGWR continues writing to otherfiles in the group and writes an error to the LGWR trace file and the alertlog. If all files in a group are damaged, or if the group is unavailable because it has not been archived, then LGWR cannot continue to function.

See Also:

  "How Oracle Database Writes to the Online RedoLog" and "Redo Log Buffer" 

  Oracle Database Performance Tuning Guide for information about how to monitor and tune the performance of LGWR 

Checkpoint Process (CKPT)

The checkpoint process (CKPT) updates the control file and data file headers with checkpoint information and signals DBW n to write blocks to disk.Checkpoint information includes the checkpoint position, SCN, location in

online redo log to begin recovery, and so on. As shown in Figure 15-4, CKPTdoes not write data blocks to data files or redo blocks to online redo logfiles.

Figure 15-4 Checkpoint Process

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 24/32

 Description of "Figure 15-4 Checkpoint Process" 

See Also:"Overview of Checkpoints" 

 Manageability Monitor Processes (MMON and MMNL)

The manageability monitor process (MMON) performs many tasks related to

the  Automatic Workload Repository (AWR). For example, MMON writes whena metric violates its threshold value, taking snapshots, and capturingstatistics value for recently modified SQL objects.

The manageability monitor lite process (MMNL) writes statistics from the Active Session History (ASH) buffer in the SGA to disk. MMNL writes to disk when the ASH buffer is full.

See Also:"Automatic Workload Repository (AWR)" and  "Active Session History(ASH)" 

Recoverer Process (RECO)

In a distributed database, the recoverer process (RECO) automaticallyresolves failures in distributed transactions. The RECO process of a nodeautomatically connects to other databases involved in an in-doubt distributed transaction. When RECO reestablishes a connection between the databases, itautomatically resolves all in-doubt transactions, removing from eachdatabase's pending transaction table any rows that correspond to the resolved transactions.

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 25/32

See Also:Oracle Database Administrator's Guide for more information about transactionrecovery in distributed systems

Optional Background Processes

 An optional background process is any background process not defined as mandatory. Most optional background processes are specific to tasks orfeatures. For example, background processes that support OracleStreams Advanced Queuing (AQ) or Oracle Automatic Storage Management (Oracle ASM) are only available when these features are enabled.

This section describes some common optional processes:

   Archiver Processes (ARCn)   Job Queue Processes (CJQ0 and Jnnn)   Flashback Data Archiver Process (FBDA)   Space Management Coordinator Process (SMCO) 

See Also:

  "Oracle Streams Advanced Queuing (AQ)"   Oracle Database Reference for descriptions of background processes

specific to AQ and ASM 

 Archiver Processes (ARCn)

The archiver processes (ARCn) copy online redo log files to offline storageafter a redo log switch occurs. These processes can also collect transactionredo data and transmit it to standby database destinations. ARCn processesexist only when the database is in  ARCHIVELOG mode and automatic archiving isenabled.

See Also:

  "Archived Redo Log Files"   Oracle Database Administrator's Guide to learn how to adjust the number

of archiver processes

  Oracle Database Performance Tuning Guide to learn how to tune archiver performance

Job Queue Processes (CJQ0 and Jnnn)

Oracle Database uses job queue processes to run user jobs, often in batch

 mode. A job is a user-defined task scheduled to run one or more times. Forexample, you can use a job queue to schedule a long-running update in the background. Given a start date and a time interval, the job queue processesattempt to run the job at the next occurrence of the interval.

Oracle Database manages job queue processes dynamically, thereby enabling jobqueue clients to use more job queue processes when required. The databasereleases resources used by the new processes when they are idle.

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 26/32

Dynamic job queue processes can run a large number of jobs concurrently at agiven interval. The sequence of events is as follows:

1.  The job coordinator process (CJQ0) is automatically started and stopped 

as needed by Oracle Scheduler (see "Oracle Scheduler"). Thecoordinator process periodically selects jobs that need to be run from 

the system JOB$ table. New jobs selected are ordered by time.2.  The coordinator process dynamically spawns job queue slave processes(Jnnn) to run the jobs.

3.  The job queue process runs one of the jobs that was selected by theCJQ0 process for execution. Each job queue process runs one job at atime to completion.

4.  After the process finishes execution of a single job, it polls for morejobs. If no jobs are scheduled for execution, then it enters a sleepstate, from which it wakes up at periodic intervals and polls for morejobs. If the process does not find any new jobs, then it terminatesafter a preset interval.

The initialization parameter JOB_QUEUE_PROCESSES represents the maximum number of

job queue processes that can concurrently run on an instance. However,clients should not assume that all job queue processes are available for jobexecution.

 Note:The coordinator process is not started if the initialization parameter JOB_QUEUE_PROCESSES is set to 0.

See Also:

  Oracle Database Administrator's Guide to learn about Oracle Schedulerjobs

  Oracle Streams Advanced Queuing User's Guide to learn about AQ background processes

Flashback Data Archiver Process (FBDA)

The flashback data archiver process (FBDA) archives historical rows oftracked tables into Flashback Data Archives. When a transaction containingDML on a tracked table commits, this process stores the pre-image of the rowsinto the Flashback Data Archive. It also keeps metadata on the current rows.

FBDA automatically manages the flashback data archive for space,organization, and retention. Additionally, the process keeps track of how farthe archiving of tracked transactions has occurred.

Space Management Coordinator Process (SMCO)

The SMCO process coordinates the execution of various space managementrelated tasks, such as proactive space allocation and space reclamation. SMCOdynamically spawns slave processes (W nnn) to implement the task.

See Also:Oracle Database Advanced Application Developer's Guide to learn aboutFlashback Data Archive

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 27/32

Slave Processes

Slave processes are background processes that perform work on behalf of other processes. This section describes some slave processes used by OracleDatabase.

See Also:Oracle Database Reference for descriptions of Oracle Database slave processes

I/O Slave Processes

I/O slave processes (Innn) simulate asynchronous I/O for systems and devicesthat do not support it. In asynchronous I/O, there is no timing requirementfor transmission, enabling other processes to start before the transmissionhas finished.

For example, assume that an application writes 1000 blocks to a disk on anoperating system that does not support asynchronous I/O. Each write occurssequentially and waits for a confirmation that the write was successful. With

asynchronous disk, the application can write the blocks in bulk and perform other work while waiting for a response from the operating system that all blocks were written.

To simulate asynchronous I/O, one process oversees several slave processes.The invoker process assigns work to each of the slave processes, who wait foreach write to complete and report back to the invoker when done. In trueasynchronous I/O the operating system waits for the I/O to complete and reports back to the process, while in simulated asynchronous I/O the slaves wait and report back to the invoker.

The database supports different types of I/O slaves, including the following:

  I/O slaves for Recovery Manager (RMAN)

 When using RMAN to back up or restore data, you can make use of I/Oslaves for both disk and tape devices.

  Database writer slaves

If it is not practical to use multiple database writer processes, suchas when the computer has one CPU, then the database can distribute I/Oover multiple slave processes. DBWR is the only process that scans the buffer cache LRU list for blocks to be written to disk. However, I/Oslaves perform the I/O for these blocks.

See Also:

  Oracle Database Backup and Recovery User's Guide to learn more aboutI/O slaves for backup and restore operations

  Oracle Database Performance Tuning Guide to learn more about database writer slaves

Parallel Query Slaves

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 28/32

In parallel execution or parallel processing, multiple processes worktogether simultaneously to run a single SQL statement. By dividing the workamong multiple processes, Oracle Database can run the statement more quickly.For example, four processes handle four different quarters in a year instead of one process handling all four quarters by itself.

Parallel execution reduces response time for data-intensive operations onlarge databases such as data warehouses. Symmetric multiprocessing (SMP) and clustered system gain the largest performance benefits from parallelexecution because statement processing can be split up among multiple CPUs.Parallel execution can also benefit certain types of OLTP and hybrid systems.

In Oracle RAC systems, the service placement of a particular service controls parallel execution. Specifically, parallel processes run on the nodes on which you have configured the service. By default, Oracle Database runs the parallel process only on the instance that offers the service used to connectto the database. This does not affect other parallel operations such as parallel recovery or the processing of GV$ queries.

See Also:

  Oracle Database Data Warehousing Guide and  Oracle Database VLDB and Partitioning Guide to learn more about parallel execution

  Oracle Real Application Clusters Administration and Deployment

Guide for considerations regarding parallel execution in Oracle RACenvironments

Serial Execution

In serial execution, a single server process performs all necessary processing for the sequential execution of a SQL statement. For example, to perform afull table scan such as SELECT * FROM employees, one server process

 performs all of the work, as shown in Figure 15-5.

Figure 15-5 Serial Full Table Scan

Description of "Figure 15-5 Serial Full Table Scan " 

Parallel Execution

In parallel execution, the server process acts as the parallel executioncoordinator responsible for parsing the query, allocating and controlling theslave processes, and sending output to the user. Given a query plan for a SQLquery, the coordinator breaks down each operator in a SQL query into parallel

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 29/32

 pieces, runs them in the order specified in the query, and integrates the partial results produced by the slave processes executing the operators.

Figure 15-6 shows a parallel scan of the employees table. The table is divided dynamically (dynamic partitioning) into load units called granules. Eachgranule is a range of data blocks of the table read by a single slave

 process, called a parallel execution server, which uses Pnnn as a name format.

Figure 15-6 Parallel Full Table Scan

Description of "Figure 15-6 Parallel Full Table Scan" 

The database maps granules to execution servers at execution time. When anexecution server finishes reading the rows corresponding to a granule, and  when granules remain, it obtains another granule from the coordinator. Thisoperation continues until the table has been read. The execution servers send results back to the coordinator, which assembles the pieces into thedesired  full table scan.

The number of parallel execution servers assigned to a single operation isthe degree of parallelism for an operation. Multiple operations within thesame SQL statement all have the same degree of parallelism 

Oracle Concepts - Database Files 

Oracle Tips by Burleson Consulting  

Oracle Database Files Concepts The final components of the Oracle architecture are the physical files where our 

information resided on disk. Oracle has several types for data files, each for a different

 purpose:

* Database datafiles

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 30/32

* Control files

* Online redo logs

* Parameter files

* Other database related files

Let’s look at each of these physical files in a bit more detail.

Database datafiles

Database datafiles are physical files stored on disk. These files are used to store data

on disk. Database datafiles are only written to by the DBWR processes that we

introduced you to earlier (there is an exception or two to this statement, but for now,

assume that this point this true).

These database datafiles are associated with Oracle ―tablespaces‖, which are ―logical‖

containers for tables and indexes.

Control files

The Control File of the database is a binary file that contains a great deal of database

information. The control file contains the database name, data about the database log

files. Oracle cannot function without valid control files.

Because the control file is so important, Oracle allows you to maintain duplicate

copies of the control file. When you have more than one control file, then you are said

to be multiplexing your control files. It is a good practice to put these multiple copies

on different disks to protect the control file. Later in this book, we will demonstrate

how to do this.

Online redo logs concepts

Think of the online redo logs like a tape recorder that records every change in the

Oracle database. As changes occur, they are regularly recorded in the online redo logs, just like you might record a movie on your VCR.

In the event that a disk crashes, you may have to replace the disk and restore the disk 

data from a backup tape. If this backup tape was several days ago, you have lost a lot

of data.

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 31/32

Fortunately, Oracle can ―replay‖ the saved transactions in the online redo logs, and re-

apply lost transactions back into the database. Many times, this means that Oracle can

recover from a crash without the DBA having to do anything other than just telling the

database to startup. We will cover the topic of online redo log files and how they

relate to database recovery in later chapters of this book.

At a minimum, Oracle requires that you have two online redo logs assigned to the

database. Oracle will write redo to the first log, and when the first log is full, Oracle

will switch to the second log and write the same redo. Each of these individual online

redo logs is known as an online redo log group.

The reason we call them groups is that there can be mirrored copies of the online redo

log files in each group. Like control files, it’s a good idea to have multiplexed copies

of the Online redo logs. Oracle allows you to define multiple copies of these files.

Each copy is called a member. Each redo log group can have one or more members.

We will discuss the online redo log files in more detail in later chapters.

Oracle Parameter file Concepts

The parameter file (sometimes called init.ora) contains configuration information for 

the database to use at startup time. The parameter file you configure how much RAM

the database is going to use, where to find the control files, where to write trace files,

and a whole host of other information. In most cases the database will not start

without a parameter file. Oracle allows you to have a manual parameter file (called a

PFILE) or a server-side parameter file (called a SPFILE).

Other Database Related Files

When working with the Oracle database you will be introduced to a number of 

different kinds of files. The following table is a list of the most common files and their 

general purpose. As we proceed through the chapters of this book, you will be

introduced to many of these files in more detail.

* Oracle Trace Files - Created by Oracle in a number of different situations. These can

 be created as a result of a database crash, a session failure, an unexpected but non-

fatal database failure, or based on specific user operational commands.

* Alert log - This is the general log file for each Oracle database.

 Networking configuration files - These files are used to configure the different

network components of the Oracle database. These include files such as tnsnames.ora

and listener.ora.

7/28/2019 Oracle Process

http://slidepdf.com/reader/full/oracle-process 32/32

* Oracle Database Software Binaries - The Oracle Database software includes the

 basic programs that allow the database to function