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 database metadata. 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 during database 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 configured accordingly. 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 that these concepts can provide a basis for understanding instance management. The following topics are discussed:
  

Instance Memory Structure Oracle Background Processes Accessing the Database

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 optimal values 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 SGA that 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 Log Buffer

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

Component Description files are discussed in "Redo Log Files". Large Pool Java Pool Streams Pool This is an optional area that is used for buffering large I/O requests for various server processes. The Java pool memory is used for all session-specific Java code and data within the Java Virtual Machine (JVM) 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 write data 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. They asynchronously 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: Background Process

Description

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

The log writer process writes redo log entries to disk. This event is called a checkpoint. At specific times. Authorization to use these privileges occurs either through the operating system or through a special password file. but have no privileges to access user objects. "Performing Backup and Recovery". Process Monitor The process monitor performs process recovery when a user process fails. one or more archiver processes copy the redo log files to archival storage when the log files are full or a log switch occurs. There are two of these privileges: SYSDBA for fully empowered database administrators and SYSOPER for users who operate the database. see Chapter 9. Archiver (ARCn) When the database is running in archive log mode. all modified database buffers in the SGA are written to the datafiles by a database writer process (DBWn). The checkpoint process is responsible for signalling DBWn at checkpoints and updating all of the datafiles and control files of the database to indicate the most recent checkpoint. Redo log entries are generated in the redo log buffer of the SGA and the log writer process writes the redo log entries sequentially into an online redo log file. you will learn how to start up and shut down an Oracle instance and database in "Shutting Down and Restarting the Instance and Database".Background Process (DBWn) Log Writer (LGWR) Checkpoint Description the files on disk. Oracle allows a maximum of 20 database writer processes. After the database instance has been started. it is usually open for access by normal users for whom database user accounts have been created. System Monitor The system monitor performs crash recovery when a failed instance starts up (SMON) again. For more information. Later. How the Oracle Instance and Database are Started The administrator who starts up the Oracle instance and database must connect to the instance with a special kind of connection privilege. Accessing the Database The database instance can be started (made available) only by an authorized database administrator who has a special type of connection privilege to the Oracle instance. This section describes the process of starting the Oracle instance and database and the creation of server processes that enable user access. It is (PMON) responsible for cleaning up the cache and freeing resources that the failed process was using. .

there are two primary administrative user accounts who are automatically created: SYS and SYSTEM. allocates SGA memory. Oracle reads the initialization parameter file. 1. the instance will be started. 3.When you create an Oracle database. database mounted and opened. Any modified data blocks that are cached in the SGA and have not been written to disk are now written to disk. you can start the Oracle services. This state enables administrators to perform certain administrative functions that cannot be performed when other users are accessing the database. See "Shutting Down and Restarting the Instance and Database". The database is now closed and only the instance remains. Server and Client Processes . but only user SYS can initially connect with the SYSDBA privilege. The database is now said to be in the mount state. 2. Users can no longer access the database. Datafiles and log files are closed. See "Starting and Shutting Down the Database Instance on Windows".  Use the STARTUP statement using SQL*Plus. See Oracle Database Administrator's Guide  On Windows. Both of these users have full database administration privileges granted to them. Datafiles are checkpointed and their headers are marked current as of the time the database was closed. The control file is closed. The Startup Process The process of starting the instance and database is as follows: 1. The Oracle instance dismounts the database and updates relevant entries in the control file to record a clean shutdown. You issue the statement to shutdown the database by similar means as explained in "The Startup Process". then the instance opens the database control file. The database is now open and available for all user access. The default startup behavior is to complete the three stages as described earlier. The Oracle instance stops the background processes of the instance and deallocates the shared memory used by the SGA. The redo log buffer is similarly flushed. If you also specify that the database is to be mounted. The Shutdown Process The process is reversed when you shut down the database. then the instance opens the redo log files and datafiles for the database. You start the instance in one of the following ways:  Use Oracle Enterprise Manager. Unless explicitly specified otherwise. If you specify that the database is to be opened. and starts the background processes for the instance.

see Chapter 4. which means a small number of shared servers can perform the same amount of processing as many dedicated servers. Shared server mode eliminates the need for a dedicated server process for each connection. You can configure Oracle Net using Oracle Enterprise Manager or with a separately launched GUI tool called the Oracle Net Manager. Oracle Net enables the client and server to communicate over a network using many popular network protocols. A version of Oracle Net runs on the client machine and on the database server. you only need to reconfigure Oracle Net. Also. a user process always communicates with Oracle through a separate server process. an idle process or too many dedicated processes can result in an inefficient use of resources. While a dedicated server process is good for long running queries and administrative tasks. No changes are necessary to client applications. However. Network Connections Oracle Net is a layer of software that allows different physical machines to communicate to accessing an Oracle database. Shared server mode is more efficient at supporting multiple users and clients making frequent short-running queries.In addition to background processes. and more users can be supported. and it provides location transparency such that the client machine does not need to know the server's location. such as Oracle Enterprise Manager. because the amount of memory required for each user is relatively small. In dedicated server mode. A dispatcher directs multiple incoming network session requests to a pool of shared server processes. Oracle Net must be separately configured and started for it to handle client connections to the database. it is possible to combine the user process and corresponding server process into a single process to reduce system overhead. To learn more. 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. Server processes can be either dedicated or shared. The client machine and the database server are often the same machine. each client process has its own server process. less memory and process management are required. SQL*Plus. A user connection is composed of two distinct pieces:   A client program acting on behalf of the user. . When the database is moved to another location. " Configuring the Network Environment ". when the client and Oracle operate on different machines. Oracle creates server processes that handle the requests of user or client processes that connect to the instance. An idle shared server process from a shared pool of server processes picks up a request from a common queue.

the listener determines whether it should use a shared server dispatcher process or a dedicated server process and establishes an appropriate connection.  Text initialization parameter file This type of initialization parameter file can be read by the database server. It resides on the machine that Oracle is running on. where many of them can be changed dynamically.When an instance starts. It must not be edited manually. you can do this with the Shutdown or Startup button. In this file. Shutting Down and Restarting the Instance and Database If you need to shut down and later restart your instance or database. but it is not written to by the server. Figure 5-1 Shutdown/Startup Button on Home Page . is contained in a binary file that can be written to and read by the database server. These parameters are called initialization parameters. The Oracle database server reads these parameters at database startup and monitors them while the database is running. They are stored in memory. you can set initialization parameters with a text editor for them to be persistent across shutdown and startup.  Server parameter file This. When a user process makes a connection request. and is persistent across shutdown and startup. under the General heading on the Database Home page as shown in Figure 5–1. About Initialization Parameters Instance management involves configuring parameters that affect the basic operation of the database instance. There are two types of parameter files. the preferred form of initialization parameter file. a listener process establishes a communication pathway to Oracle. and whether these dynamic changes are persistent across database shutdown and startup depends upon the type of parameter file you are using. "Shutdown/Startup Button on Home Page".

Starting and Shutting Down the Database Instance on Windows You can start and shut down your Oracle database with the Windows Services program. which is your listener required to allow clients to connect to your database Oracle<oracle_home><SID>DBConsole. You can also choose Start from the Actions menu. you must start three services:    OracleService<SID>. If you double click the service. or start up the database. which is your Oracle Database instance Oracle<oracle_home><SID>TNSListener. which enables clients to connect to Enterprise Manager To start these services: 1. and into the database itself with SYSDBAor SYSOPER privileges.gif The first page to appear is Startup/Shutdown: Specify Host and Target Database Credentials. . From the Control Panel. the service properties page appears where you can Start or Stop the service. For example.Description of the illustration hp-shutdown. then locate the following services:  OracleServiceSales1  OracleOraHome10Sales1TNSListener  OracleOraHome10Sales1DBConsole Start all three services. The next screen enables you to shut down the database. Locate the three Oracle services listed earlier. You can start a service by right-clicking the service. select Administrative Tools->Services. specifying options. 2. and selecting Start. A list of all available services on you system appears. if your SID is Sales1 and Oracle home is OraHome10. This page requires you to log in to the machine that Oracle is running on. To start Oracle. and select your Startup Type.

To shut down the database. The steps described in this section will familiarize you with the initial parameter setting for your database and indicate how to modify parameters. click the Administration property page. Viewing and Modifying Initialization Parameters When you install one of the preconfigured databases provided by Oracle. To view or modify the initialization parameters for your database: 1. It is not necessary for you to alter any initialization parameters at this time. Figure 5-2 Database Administration Page . The next page that you see is the Administration home page shown in Figure 5-2. the initialization parameters are optimized for normal use in the environment that you specified. From the Database Home page. by selecting Stop from the Actions menu. you do the reverse: locate the services and stop them.

gif .Description of the illustration admin-page-updated1.

Only parameters marked dynamic can be changed. enter a new value and click Apply. and Apply buttons. . enter the new value and click Apply. you might need to alter some initialization parameters. using the Show SQL. Changes to parameter settings in this file are persistent across instance startup and shutdown. is described in "Managing Memory Parameters".2. When you install your database. determine the total size of the system global area (SGA) and the program global area (PGA). Parameters marked as Basic represent a small subset of all initialization parameters. or indirectly using one of the advisors provided by Oracle. 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). This property page shows parameter settings in the server parameter file. If you do not check this box. As the number of database users grows and workload increases. You can optionally apply changes to the current running instance by checking Apply changes in SPFile to the current running instance. referred to here as memory parameters. these parameters are tuned to meet the requirements of the environment that you specify. To make persistent changes to an initialization parameter. You can make these changes directly using the Initialization Parameter page as described. your changes will not take effect until the database is shut down and restarted. You can also use this page to alter initialization parameter values. the memory advisor. Revert. Click All Initialization Parameters under the Instance heading. Managing Memory Parameters Some initialization parameters. and are considered necessary to keeping the database running and healthy. Enterprise Manager displays the Initialization Parameters page comprised of a table listing the current value of each initialization parameter as seen by the database instance. One such advisor. whose location is displayed a the top of the table. and of the subcomponents of the SGA. The settings of memory parameters can affect the performance of your database.  SPFile—This property page is present when you are using a server parameter file. You can use this page to make dynamic changes to parameters in the current running instance. To do so.

You can also do so from the Current property page on the Initialization Parameters page. you can enter new sizes and apply changes dynamically while the instance is up. an Oracle background process is a thread of execution within a process. the Memory Advisor (discussed in "Using the Memory Advisor" in Chapter 10. If you choose to modify your memory settings manually. If Automatic Shared Memory Management is disabled. see Oracle Database Administrator's Guide. From this page you can enable or disable Automatic Shared Memory Management and view your SGA and PGA memory settings from their property pages. 15 Process Architecture This chapter discusses the processes in an Oracle database. For example. Oracle automatically sizes the subcomponents of the SGA. Oracle recommends that you enable memory auto tuning. 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. However. you can disable Automatic Shared Memory Management on the Memory Parameters page. You can do so by navigating to SPFile property page from the Memory Parameters page and making your changes there. there are some restrictions on dynamic modification of memory parameters. "Monitoring and Tuning the Database") gives you advice on optimal memory settings. With the Advice button on the Memory Parameters page. on Linux an Oracle background process is a Linux process. which include the shared pool and buffer cache. You can navigate to this page from the Administration page by clicking Memory Parametersunder the Instance heading. you can enable it on the Memory Parameters page. you must alter your parameter file. Modifying Memory Parameters To modify the size of an SGA subcomponent without bringing your instance down. The mechanism depends on the operating system. For more information.If you enabled Automatic Shared Memory Configuration when you configured your database. On Windows. . To make changes to memory parameters persistent across instance startup and shutdown.

 Oracle database code Each user has Oracle database code executing on his or her behalf that interprets and processes the application's SQL statements. writing redo buffers to disk. create and execute a query plan for each query. and read buffers from the database buffer cache or from disk. A process normally runs in its own private memory area. that issues SQL statements to a database. For example. Ticatatabase Systems). these processes parse SQL queries.Code modules are run by processes.Ticathat cangivepsgoodcallbasman> Types of Processes A database instance contains or interacts with the following types of processes:   Client processes run the application or Oracle tool code. o Server processes perform work based on a client request. Note: . cleaning up processes. such as a precompiler program or a database tool such as SQL*Plus. and so on. Most processes can periodically 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. All connected Oracle Database users must run the following modules to access a database instance:  Application or Oracle Database utility A database user runs a database application. place them in the shared pool. 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 instance recovery.

Figure 15-1 Oracle Processes and the SGA . The instance continues to function when server processes terminate.Server processes. For example. o Slave processes perform additional tasks for a background or server process. Figure 15-1 shows a system global area (SGA) and background processes using dedicated server connections. which has its own program global area (PGA). Each client process is associated with its own server process. the application is run by a client process that is different from the dedicated server process that runs the database code. each server process that runs database code can serve multiple client processes. and the process memory allocated in these processes. run in the instance. the code for connected users can be configured for dedicated server or shared server connections. The process structure varies depending on the operating system and the choice of Oracle Database options. In a shared server architecture. For each user connection.

the operating system creates a client process (sometimes called a user process) .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 for more 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.

Typically. A single connection can have 0. Client and Server Processes Client processes differ in important ways from the Oracle processes interacting directly with the instance. For eacer Procsrsiop>A connection is a physical communication pathway between a client process and a database instance. For example. a connection occurs between a client process and a server process or dispatcher. Ticats the applbaseeproer/"w sqlpl> nr="w sese piew a hrefarocess that runsinstaay rnn thlon. Eachessas of ure.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 -e sqlpl>< | grep -v grep ocess an a29437a29436 0cle:40 pts/1 00:00:00 sqlpl>< asneatdba!--precle dannt prcode. the applibodeno ocess can read>  ps oxml:"0" e="pre2/e25" cclass=arn" summarypr% ps -ef | grep -e sese p -e sqlpl>< | grep -v grep ocess an a29441 1 0cle:40 ? 00:00:00 oraclesese p (LOCAL=NO)!--preculid="i1Headect2">Multipld="ii16690" na8532i16690"> <7iv class="sect2"> Types of Cs.to run the user application. The client application has Oracle Database libraries linked into it that provide the APIs required to communicate with the database. The sessions are independent: a commit in one session does not affect transactions in other sessions. A session is a logical entity in the database instance memory that represents the state of a current user login to a database. when a user is authenticated by the database with a password. A session lasts from the time the user is authenticated by the database until the time the user disconnects or exits the database application. 1. a session is established for this user. or more sessions established on it. Note: . A communication pathway is established using available interprocess communication mechanisms or network software. but it can also occur between a client process and Oracle Connection Manager (CMAN). The Oracle processes servicing the client process can read a serrs fOraclr Pr an assoc/a> n fvide tns an ant request.s.

As shown in Figure 15-2. In dedicated server connections. Only the client process that causes the dedicated server to be created uses it. 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. the database creates a server process on behalf of each connection.If Oracle Net connection pooling is configured. In a shared server connection. but this connection has two sessions. Figure 15-3 Two Sessions in One Connection Description of "Figure 15-3 Two Sessions in One Connection" . Multiple sessions can exist concurrently for a single database user. then it is possible for a connection to drop but leave the sessions intact. user hrcan have multiple connections to a database.

not the connection. A client process always communicates with a database through a separate server process.. userrn. PADDR FROM V$SESSION WHERE USERNAME = USER. SERIAL#. the ig.1onnection"  ps oxml:"0" e="pre2/e25" cclass=arn" summaryproQL> SELECT SID. Example 15-2 Connection with No Sessions v WHERE ADDR = HEXTORAW('41C . when/a>.Generating an autotrace report of SQL statement execution statistics reicd to-s a servssioncenario href="#BABDBIJC"BFigure 15-3 illus.roQL> SELECT SID.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 the instance. SID SERIAL# PADDR --. the query in Example 15-2 shows that the connection from Example 15-1 is still active. SERIAL#. PADDR FROM V$SESSION WHERE USE = USER. ').-------------. PROGRAM -----------------------------------------------oracle@stbcs09. SQL> DISCONNECT   The DISCONNECT command in Example 15-1 actually ends the sessions. Opening a new terminal and connecting to the instance as a different user.. SID SERIAL# PADDR -ss=-------=------..90 91 3BE2E41C roQL> SET AUTOTRACE ON STATISTICS.88 93 3BE2E41C 90 91 3BE2E41C .ef="#BABDBIJC"CADBan E.. Server processes created on behalf of a database application can perform one or more of the following tasks:  Parse and run SQL statements issued through the application. that ilsoc/a>hr has a te a nnterilsr" celdata ils a s autork won does n(sese p outpcan the feddiv class="infoboxne. whencl"BABBCEEF"GDIIB="BABBCEEF"GDIIB=a id="CNCPT89081" nam2="CNCPT89081">. whenclass="titleinfiguree. including creating and executing the query plan (see "Stages of SQL Processing") Execute PL/SQL code  .

This server process is dedicated to its client process for the duration of the session. LGWR signals another process to archive the file. Like a dedicated server process. The dispatcher process receives requests from connected clients and puts them into a request queue in the large pool (see "Large Pool"). 20 client processes connected to a database instance are serviced by 20 server processes. The background processes perform maintenance tasks required to operate the database and to maximize performance for multiple users. 20 client processes can connect to a single dispatcher process. On Linux. the UGA for a session is in the SGA so that any shared server can access session data. a shared server process has its own PGA. client applications connect over a network to a dispatcher process. Each background process has a separate task. Overview of Background Processes A multiprocess Oracle database uses some additional processes called background processes. For example. Each client process communicates directly with its server process. the shared server place the result into the dispatcher response queue. Shared Server Processes In shared server connections. not a server process (see "Shared Server Architecture"). The dispatcher process monitors this queue and transmits the result to the client. For example. but works with the other processes. When a filled log file is ready to be archived.  Read data blocks from data files into the database buffer cache (the DBWn background process has the task of writing modified blocks back to disk) Return results in such a way that the application can process the information Dedicated Server Processes In dedicated server connections. The server process stores process-specific information and the UGA in its PGA (see "PGA Usage in Dedicated and Shared Server Modes"). the LGWR process writes data from the redo log buffer to the online redo log. the client connection is associated with one and only one server process (see "Dedicated Server Architecture"). Afterward. However. The first available shared server process takes the request from the queue and processes it. Oracle Database creates background prosses access utoon aite to a fillbase instance are h theuteratr/span> .

PMON also registers information about the instance and dispatcher processes with the Oracle Net listener (see "The Oracle Net Listener"). When an instance starts. VKTM.!--precle d servern is asthe fellowing sectionstopicul>  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 database configurations. ps oxml:"0" e="pre2/e25" cclass=arn" summaryproELECT P= USE FROM V$code> v WHERE P= USEIS NOT NULL ORDER BY P= US. 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 See Also:   Process Monitor Process (PMON) The process monitor (PMON) monitors the other background processes and performs process recovery when a server or dispatcher process terminates abnormally. For example. releases locks that are no longer required. and removes the process ID from the list of active processes. This section describes the following mandatory background processes:        Process Monitor Process (PMON) System Monitor Process (SMON) Database Writer Process (DBWn) Log Writer Process (LGWR) Checkpoint Process (CKPT) Manageability Monitor Processes (MMON and MMNL) Recoverer Process (RECO) Oracle Database Reference for descriptions of other mandatory processes. PMON is responsible for cleaning up the database buffer cache and freeing resources that the client process was using. PMON resets the status of the active transaction table. DIAG. These processes run by default in a database instance started with a minimally configured initialization parameter file (see Example 131). including MMAN. . PMON polls the listener to determine whether it is running. DBRM.

then SMON cleans up the temporary space. System Monitor Process (SMON) The system monitor process (SMON) is in charge of a variety of system-level cleanup duties. If it is not running. Other processes can call SMON if they detect a need for it. DBWn performs multiblock writes when possible to improve efficiency. Thus. The duties assigned to SMON include:   Performing instance recovery. at instance startup. thfulperauncess Orastems. Oracle Database allocates extents when creating an index.  In many cases the blocks that DBWn writes are scattered throughout the disk.   SMON checks regularly to see whether it is needed. if necessary. DBWn writes dirty buffers to disk asynchronously if possible while performing other processing. then PMON periodically attempts to contact it. the writes tend to be slower than the sequential writes performed by LGWR. The DBWn process writes dirty buffers to disk under the following conditions:  When a server process cannot find a clean reusable buffer after scanning a threshold number of buffers. The log position of the checkpoint is determined by the oldest dirty buffer in the buffer cache. If the operation fails. then PMON passes it relevant parameters. Database Writer Process (DBWn) Thedispae with a er Propess (DBW is es dataonnectits witfilabase buffer cas soc n backcesses withan asfied blocker cas database instanfer cache andisk)). In an Oracle RAC database. 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. SMON recovers the transactions when the tablespace or file is brought back online.If the listener is running.">n backcesses wit no lor. it signals DBWn to write. Recovering terminated transactions that were skipped during instance recovery because of file-read or tablespace offline errors. Coalescing contiguous free extents within dictionary-managed tablespaces. which is the position in the redo thread from which instance recovery begins (see"Overview of Checkpoints"). The number of blocks written in a multiblock write varies by operating system. Cleaning up unused temporary segments. the SMON process of one database instance can perform instance recovery for a failed instance. See Also: . For example. DBWn periodically writes buffers to advance the checkpoint.

An online redo log switch occurs. LGWR writes all redo entries that have been copied into the buffer since the last time it wrote:      A user commits a transaction (see "Committing Transactions"). The redo entries become permanent only if the transaction later commits. When activity is high. The redo log buffer is circular. LGWR puts a commit record in the redo log buffer and writes it to disk immediately. server processes can copy new entries over the entries in the redo log buffer that have been written to disk. and performing fast sequential writes of redo to disk. along with the commit SCN and transaction's redo entries. Oracle Database returns a success code to the committing transaction although the data buffers have not yet been written to disk. LGWR can use group commits. the transaction is assigned a system change number (SCN). Three seconds have passed since LGWR last wrote. causing LGWR to write the transaction's redo entries to disk. When LGWR writes redo entries from the redo log buffer to an online redo log file. Note: LGWR can write redo log entries to disk before a transaction commits. and tuning DBWn Log Writer Process (LGWR) The log writer process (LGWR) manages the redo log buffer. monitoring. During . The redo log buffer is one-third full or contains 1 MB of buffered data. The atomic write of the redo entry containing the transaction's commit record is the single event that determines the transaction has committed.Oracle Database Performance Tuning Guide for advice on configuring. LGWR and Commits Oracle Database uses a fast commit mechanism to improve performance for committed transactions. performing scattered writes of dirty buffers to disk. Before DBWn can write a dirty buffer. For example. even when access to the online redo log is heavy. a user commits. it signals LGWR to write the records to disk and waits for LGWR to complete before writing the data buffers to disk. DBWn must write modified buffers to disk. LGWR normally writes fast enough to ensure that space is always available in the buffer for new entries. When a user issues a COMMIT statement. By separating the tasks of modifying database buffers. the database improves performance. In the following circumstances. The corresponding changes to data blocks are deferred until it is efficient for DBWn to write them to the data files. redo records associated with changes to the buffer must be written to disk (the write-ahead protocol). LGWR writes one contiguous portion of the buffer to the online redo log. If DBWn finds that some redo records have not been written.

If a log file is inaccessible. SCN. Figure 15-4 Checkpoint Process . or if the group is unavailable because it has not been archived. See Also:   "How Oracle Database Writes to the Online Redo Log" 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 DBWn to write blocks to disk. As shown in Figure 15-4. Checkpoint information includes the checkpoint position. then LGWR continues writing to other files in the group and writes an error to the LGWR trace file and the alert log. LGWR cannot write to disk to commit these transactions until its previous write completes. LGWR can write the list of redo entries of waiting transactions (not yet committed) in one operation. In this way. location in online redo log to begin recovery. Upon completion. and so on. then every write by LGWR can contain multiple commit records. LGWR and Inaccessible Files LGWR writes synchronously to the active mirrored group of online redo log files.this write other users commit. If commits requests continue at a high rate. If all files in a group are damaged. then LGWR cannot continue to function. CKPT does not write data blocks to data files or redo blocks to online redo log files. the database minimizes disk I/O and maximizes performance.

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). taking snapshots. The RECO process of a node automatically connects to other databases involved in an in-doubt distributed transaction. removing from each database's pending transaction table any rows that correspond to the resolved transactions. See Also: "Automatic Workload Repository (AWR)" and "Active Session History (ASH)" Recoverer Process (RECO) In a distributed database. and capturing statistics value for recently modified SQL objects. . it automatically resolves all in-doubt transactions. The manageability monitor lite process (MMNL) writes statistics from the Active Session History (ASH) buffer in the SGA to disk. the recoverer process (RECO) automatically resolves failures in distributed transactions. MMON writes when a metric violates its threshold value. When RECO reestablishes a connection between the databases. MMNL writes to disk when the ASH buffer is full. For example.

For example. 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. The database releases resources used by the new processes when they are idle. you can use a job queue to schedule a long-running update in the background. ARCn processes exist only when the database is in ARCHIVELOG mode and automatic archiving is enabled. Most optional background processes are specific to tasks or features. Given a start date and a time interval. These processes can also collect transaction redo data and transmit it to standby database destinations. background processes that support Oracle Streams Advanced Queuing (AQ) or Oracle Automatic Storage Management (Oracle ASM) are only available when these features are enabled. Oracle Database manages job queue processes dynamically. For example. . often in batch mode. thereby enabling job queue clients to use more job queue processes when required.See Also: Oracle Database Administrator's Guide for more information about transaction recovery in distributed systems Optional Background Processes An optional background process is any background process not defined as mandatory. A job is a user-defined task scheduled to run one or more times. 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) "Oracle Streams Advanced Queuing (AQ)" Oracle Database Reference for descriptions of background processes specific to AQ and ASM See Also:   Archiver Processes (ARCn) The archiver processes (ARCn) copy online redo log files to offline storage after a redo log switch occurs. the job queue processes attempt to run the job at the next occurrence of the interval.

If the process does not find any new jobs. The coordinator process dynamically spawns job queue slave processes (Jnnn) to run the jobs. When a transaction containing DML on a tracked table commits. clients should not assume that all job queue processes are available for job execution. The coordinator process periodically selects jobs that need to be run from the system JOB$ table. 2. 3. the process keeps track of how far the archiving of tracked transactions has occurred. After the process finishes execution of a single job. See Also:  Oracle Database Administrator's Guide to learn about Oracle Scheduler jobs  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 of tracked tables into Flashback Data Archives. New jobs selected are ordered by time. 4. However. Additionally. The initialization parameter JOB_QUEUE_PROCESSES represents the maximum number of job queue processes that can concurrently run on an instance. Each job queue process runs one job at a time to completion. See Also: Oracle Database Advanced Application Developer's Guide to learn about Flashback Data Archive .Dynamic job queue processes can run a large number of jobs concurrently at a given interval. it polls for more jobs. The sequence of events is as follows: 1. If no jobs are scheduled for execution. organization. and retention. Space Management Coordinator Process (SMCO) The SMCO process coordinates the execution of various space management related tasks. FBDA automatically manages the flashback data archive for space. this process stores the pre-image of the rows into the Flashback Data Archive. then it enters a sleep state. from which it wakes up at periodic intervals and polls for more jobs. SMCO dynamically spawns slave processes (Wnnn) to implement the task. It also keeps metadata on the current rows. such as proactive space allocation and space reclamation. then it terminates after a preset interval. The job queue process runs one of the jobs that was selected by the CJQ0 process for execution. The job coordinator process (CJQ0) is automatically started and stopped as needed by Oracle Scheduler (see "Oracle Scheduler"). Note: The coordinator process is not started if the initialization parameter JOB_QUEUE_PROCESSES is set to 0.

The invoker process assigns work to each of the slave processes. there is no timing requirement for transmission. In true asynchronous I/O the operating system waits for the I/O to complete and reports back to the process. With asynchronous disk. For example.Slave Processes Slave processes are background processes that perform work on behalf of other processes. while in simulated asynchronous I/O the slaves wait and report back to the invoker. The database supports different types of I/O slaves. DBWR is the only process that scans the buffer cache LRU list for blocks to be written to disk. To simulate asynchronous I/O. one process oversees several slave processes. I/O slaves perform the I/O for these blocks. 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. including the following:  I/O slaves for Recovery Manager (RMAN) When using RMAN to back up or restore data.  Database writer slaves If it is not practical to use multiple database writer processes. then the database can distribute I/O over multiple slave processes. you can make use of I/O slaves for both disk and tape devices. enabling other processes to start before the transmission has finished. This section describes some slave processes used by Oracle Database. assume that an application writes 1000 blocks to a disk on an operating system that does not support asynchronous I/O. 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 devices that do not support it. who wait for each write to complete and report back to the invoker when done. Each write occurs sequentially and waits for a confirmation that the write was successful. However. such as when the computer has one CPU. See Also:   Oracle Database Backup and Recovery User's Guide to learn more about I/O slaves for backup and restore operations Oracle Database Performance Tuning Guide to learn more about database writer slaves Parallel Query Slaves . In asynchronous I/O.

This does not affect other parallel operations such as parallel recovery or the processing of GV$ queries. Figure 15-5 Serial Full Table Scan Description of "Figure 15-5 Serial Full Table Scan " Parallel Execution In parallel execution. By default. a single server process performs all necessary processing for the sequential execution of a SQL statement. 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 RAC environments Serial Execution In serial execution. to perform afull table scan such as SELECT * FROM employees.In parallel execution or parallel processing. By dividing the work among multiple processes. the service placement of a particular service controls parallel execution. For example. Parallel execution can also benefit certain types of OLTP and hybrid systems. as shown in Figure 15-5. In Oracle RAC systems. Oracle Database runs the parallel process only on the instance that offers the service used to connect to the database. allocating and controlling the slave processes. multiple processes work together simultaneously to run a single SQL statement. Symmetric multiprocessing (SMP) and clustered system gain the largest performance benefits from parallel execution because statement processing can be split up among multiple CPUs. the server process acts as the parallel execution coordinator responsible for parsing the query. Specifically. For example. Oracle Database can run the statement more quickly. Given a query plan for a SQL query. the coordinator breaks down each operator in a SQL query into parallel . one server process performs all of the work. Parallel execution reduces response time for data-intensive operations on large databases such as data warehouses. parallel processes run on the nodes on which you have configured the service. and sending output to the user. four processes handle four different quarters in a year instead of one process handling all four quarters by itself.

pieces. Oracle has several types for data files. each for a different purpose: * Database datafiles . Multiple operations within the same SQL statement all have the same degree of parallelism Oracle Concepts . it obtains another granule from the coordinator. This operation continues until the table has been read. 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.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. When an execution server finishes reading the rows corresponding to a granule. The execution servers send results back to the coordinator. and integrates the partial results produced by the slave processes executing the operators. runs them in the order specified in the query. The number of parallel execution servers assigned to a single operation is the degree of parallelism for an operation. Figure 15-6 shows a parallel scan of the employees table. called a parallel execution server. The table is divided dynamically (dynamic partitioning) into load units called granules. and when granules remain. which assembles the pieces into the desired full table scan. Each granule is a range of data blocks of the table read by a single slave process.

As changes occur. These database datafiles are associated with Oracle ―tablespaces‖. 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. which are ―logical‖ containers for tables and indexes. Database datafiles Database datafiles are physical files stored on disk. Because the control file is so important. It is a good practice to put these multiple copies on different disks to protect the control file. Oracle cannot function without valid control files. Oracle allows you to maintain duplicate copies of the control file. The control file contains the database name. then you are said to be multiplexing your control files. just like you might record a movie on your VCR. but for now. These files are used to store data on disk. they are regularly recorded in the online redo logs. When you have more than one control file. Online redo logs concepts Think of the online redo logs like a tape recorder that records every change in the Oracle database. .* 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. If this backup tape was several days ago. Later in this book. you have lost a lot of data. you may have to replace the disk and restore the disk data from a backup tape. Control files The Control File of the database is a binary file that contains a great deal of database information. In the event that a disk crashes. we will demonstrate how to do this. assume that this point this true). data about the database log files.

As we proceed through the chapters of this book. We will cover the topic of online redo log files and how they relate to database recovery in later chapters of this book. .Fortunately. Oracle can ―replay‖ the saved transactions in the online redo logs.Created by Oracle in a number of different situations. Each redo log group can have one or more members. Networking configuration files . Many times. an unexpected but nonfatal database failure. Other Database Related Files When working with the Oracle database you will be introduced to a number of different kinds of files. * Oracle Trace Files .This is the general log file for each Oracle database. The following table is a list of the most common files and their general purpose. where to find the control files. Oracle requires that you have two online redo logs assigned to the database.These files are used to configure the different network components of the Oracle database. At a minimum. and a whole host of other information. and reapply lost transactions back into the database. These can be created as a result of a database crash. you will be introduced to many of these files in more detail. We will discuss the online redo log files in more detail in later chapters. and when the first log is full.ora. Each of these individual online redo logs is known as an online redo log group. The parameter file you configure how much RAM the database is going to use. where to write trace files. 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). Like control files. this means that Oracle can recover from a crash without the DBA having to do anything other than just telling the database to startup.ora and listener. The reason we call them groups is that there can be mirrored copies of the online redo log files in each group. Oracle will switch to the second log and write the same redo. a session failure. Each copy is called a member.ora) contains configuration information for the database to use at startup time. it’s a good idea to have multiplexed copies of the Online redo logs. Oracle Parameter file Concepts The parameter file (sometimes called init. * Alert log . These include files such as tnsnames. or based on specific user operational commands. Oracle allows you to define multiple copies of these files. Oracle will write redo to the first log.

* Oracle Database Software Binaries .The Oracle Database software includes the basic programs that allow the database to function .

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.